You are on page 1of 201

DOC 99-70-02

PHARE Ground Human Machine Interface (GHMI) project: Summary report


PHARE/NLR/GHMI-7/FR/1.0

EUROCONTROL 96 rue de la Fuse B-1130 BRUXELLES

Prepared by:

P.G.A.M. Jorna NLR, D. Pavet CENA, M. van Blanken NLR, I. Pichancourt EEC August 99

Date:

Copyright Statement

PHARE GHMI project, Final Report

The information contained in this report is the property of the PHARE Participants*. The report or parts thereof may be published and or reproduced on the condition that due acknowledgement of authorship is made by quoting the copyright statement below. The copyright and the foregoing condition on publication and reproduction shall extend to all media in which the information may be embodied. The information contained in this document is provided on an "as-is" basis and the PHARE Participants shall provide no express or implied warranty of any kind and shall accept no liability whatsoever for or in connection with the use of the information contained in the document. * The PHARE Participants are: - the EUROCONTROL Agency; - the CENA (Centre d'tudes de la navigation arienne); - the STNA (Service technique de la navigation arienne); - the NLR (Nationaal Lucht- en Ruimtevaartlaboratorium); - the RLD (Rijksluchtvaartdienst); - the LVNL (Luchtverkeersleiding Nederland); - the DLR (Deutsches Zentrum fr Luft- und Raumfahrt); - the DFS (Deutsche Flugsicherung GmbH); - the UK CAA (Civil Aviation Authority); - the NATS (National Air Traffic Services); - the DERA (Defence Evaluation and Research Agency)

Copyright statement: The copyright in this report vests in the European Organisation for the Safety of Air Navigation (EUROCONTROL); the CENA (Centre d'tudes de la navigation arienne); the STNA (Service technique de la navigation arienne); the NLR (Nationaal Lucht- en Ruimtevaartlaboratorium); the RLD (Rijksluchtvaartdienst); the LVNL (Luchtverkeersleiding Nederland); the DLR (Deutsches Zentrum fr Luft- und Raumfahrt); the DFS (Deutsche Flugsicherung GmbH); the UK CAA (Civil Aviation Authority); the NATS (National Air Traffic Services) and the DERA (Defence Evaluation and Research Agency). All rights reserved.

-2-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Revision History

REVISION HISTORY
Date Revision Number Reason for revision

Jan 99 May 99 July 99 August 99

0.2 0.3 0.4 1.0

Initial complete draft First comments from Document Review Group incorporated Further comments incorporated Publication version

DOC 99-70-02

Version 1.0 / August 1999

-3-

Document Approval

PHARE GHMI project, Final Report

DOCUMENT APPROVAL
NAME
AUTHOR 1

SIGNATURE

DATE
Sep 99

P. Jorna (NLR)

AUTHOR 2

D. Pavet (CENA)

Sep 99

AUTHOR 3

M. van Blanken (NLR)

Sep 99

AUTHOR 4

I. Pichancourt (EEC)

Sep 99

Project Leader

P. Jorna (NLR)

Sep 99

PHARE Programme Manager

H. Schrter (EUROCONTROL)

Sep 99

-4-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Executive Summary

EXECUTIVE SUMMARY
The GHMI project was aimed at developing a next generation of controller working positions to be used in future Air Traffic Management concepts. It was part of the PHARE programme and was responsible for the delivery of the Human Machine Interface (HMI) specifications. An international team that combined Human Factors specialists with engineers and operational experts performed the work. The resulting specifications were based on multi-disciplinary expertise, extensive user interaction and practical support provided by means of exploratory Human Factors studies considering overall automation philosophies, possible applications of software tools like conflict detection, problem solvers etc. The report will provide a historic overview of the project, as it developed over a period approaching almost ten years of work in the area. First of all, the results of an earlier task force on the expected Role of man in future systems will be discussed. That discussion provided some important starting points for the GHMI project definition and its overall design goals. Subsequently, the project structure and management integration in the overall programme is explained. After presenting this background material, the results of some exploratory experiments are discussed. The use of software assistance to the controller was found to reduce the controllers workload objectively, provided that the design of the tools was effective enough to be also usable under high traffic load conditions. Controllers tended to revert to old controlling strategies or habits under high pressure and as a consequence sometime drop the tools. Training issues are discussed in the context of HMI familiarisation and further work is recommended. Subjective and objective workload measurements tend to dissociate, stressing the importance of objective evaluations as compared to personal opinion and the use of a more representative participant population. Four main GHMI specifications were produced, one for each segment of flight i.e. the Departure, En-route, Approach & Arrivals and the Multi-sector controller working positions. The detailed design specifications are not a part of this report as they are too lengthy for inclusion. The reader is referred to the applicable PHARE documents. The GHMI designs used advanced features with respect to the use of colour, windowing and software tools. Initially, such applications were regarded as highly experimental but in the end they were generally well received and accepted. The use of graphical direct object manipulation and other features was initially met with some sceptics, but after gaining experience with the system, appreciation increased. The role of various training facilities has been very instrumental in achieving such positive acceptance. Many of the achievements have been incorporated in other programs like EATCHIP and also the FAA has expressed interest. As early as PHARE Demonstration 1, it was learnt that transferring existing conventions onto new designs was not effective. Novel features of the environment that were initially deemed as potentially unacceptable, when brought to life in real HMI, were accepted by controllers and with further experience their potential could be exploited. The GHMI project recommends that advantage be taken of the PHARE technologies and simulation platforms, which provide a unique opportunity to investigate possible future configurations in terms of controller performance and safety. Exploratory studies should also be made into integration of airborne separation assurance and the PHARE ground based separation concept based on D trajectories.

-DOC 99-70-02

Version 1.0 / August 1999

-5-

PHARE GHMI project, Final Report

This page left intentionally blank

-6-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

List of Contents

LIST OF CONTENTS
1. 2. 2.1. 2.2. 2.3. 2.4. 3. 3.1. 3.2. 3.3. 4. 4.1. 4.2. 4.3. INTRODUCTION..................................................................................................... 11 THE GOALS OF THE GHMI PROJECT ................................................................... 13
THE HUMAN FACTOR ............................................................................................. 13

2.1.1. The starting points.......................................................................................... 13 THE FUTURE USERS .............................................................................................. 16


STATE OF THE ART ............................................................................................... 17 DESIGN REQUIREMENTS ........................................................................................ 18

INTEGRATION IN THE PHARE PROCESS ............................................................. 19


GHMI PROJECT STRUCTURE ................................................................................... 20 THE DESIGN PROCESS ........................................................................................... 21 THE DESIGN TEAM ................................................................................................ 21

HUMAN MACHINE COLLABORATION ................................................................... 23


AUTOMATION PHILOSOPHIES .................................................................................. 23 THE TOOLS APPROACH.......................................................................................... 24 TASK AND SKILL ANALYSIS .................................................................................... 25

4.3.1. Task-logic diagrams ....................................................................................... 27 5. 5.1. RESULTS............................................................................................................... 34


EXPLORATORY STUDIES ........................................................................................ 34

5.1.1. Input devices.................................................................................................. 34 5.1.2. Gesture recognition ........................................................................................ 38 5.1.3. Controller data link interface............................................................................ 38 5.1.4. Conflict detection and resolution tools.............................................................. 43 5.1.5. Arrival sequence tool ...................................................................................... 45 5.1.6. The Highly Interactive Problem Solver (HIPS).................................................. 47 5.2. THE GHMI TRAINING APPROACH.............................................................................. 51 5.2.1. Initial training approach................................................................................... 51 5.2.2. The CBT HMI familiarisation approach............................................................. 53 5.3. 5.2.3. Training benefits............................................................................................. 56 THE GHMI DESIGNS............................................................................................. 57 5.3.1. The en-route GHMI (PD-1).............................................................................. 57 5.3.2. The approach GHMI (PD-2) ............................................................................ 63 5.3.3. The multi-sector Gate to Gate GHMIs (PD-3)................................................... 73 6. 6.1. THE CENA/PD3 GROUND HUMAN-MACHINE INTERFACE.................................... 80 EXAMPLES OF GHMI IMPLEMENTATIONS ................................................................. 81 6.1.1. The main screen............................................................................................. 83 6.1.2. The ancillary screen........................................................................................ 83 6.2. THE TMA DEPARTURE CWP................................................................................. 84 6.2.1. The main screen............................................................................................. 85 DOC 99-70-02 Version 1.0 / August 1999 -7-

List of Contents

PHARE GHMI project, Final Report

6.3.

6.2.2. The ancillary screen........................................................................................ 85 INTEGRATION OF PHARE A DVANCED TOOLS........................................................... 86 6.3.1. Trajectory Predictor (TP)................................................................................. 86 6.3.2. Conflict Probe (CP)......................................................................................... 86 6.3.3. Flight Path Monitor (FPM) ............................................................................... 87 6.3.4. Negotiation Manager (NM) .............................................................................. 87 6.3.5. Problem Solver (PS)....................................................................................... 87 6.3.6. Departure Manager (DM) ................................................................................ 87

6.4. 6.5.

6.3.7. Co-operative tools (CT)................................................................................... 88 MAIN LESSONS LEARNT ......................................................................................... 88 GHMI DISPLAYS AND I NTERACTIONS ...................................................................... 89 6.5.1. TEPS/TST...................................................................................................... 89 6.5.2. MIW/MOW ..................................................................................................... 91 6.5.3. CRD (used only in the Baseline environment)................................................... 91 6.5.4. SIL................................................................................................................. 91 6.5.5. Advisories labels in the APD............................................................................ 92 6.5.6. Departure Manager......................................................................................... 92

7. 7.1. 7.2.

THE NLR/ PD3 GROUND HUMAN-MACHINE INTERFACE...................................... 94 AIRSPACE AND OVERVIEW GHMIS ......................................................................... 94 EXAMPLES OF GHMI IMPLEMENTATIONS ................................................................. 95 7.2.1. ACC and TMA working positions...................................................................... 95 7.2.2. Arrival Manager Display (BaseAMD) ................................................................ 97 7.2.3. Vertical View Display (VVD) ............................................................................ 98

7.3.

ROLES AND WORKING PROCEDURES ....................................................................... 99 7.3.1. Aircraft states ............................................................................................... 100 7.3.2. En-route Planning Controller.......................................................................... 101

7.4.

7.3.3. En-route Tactical Controller ........................................................................... 108 INTEGRATION OF PHARE ADVANCED TOOLS......................................................... 111 7.4.1. Trajectory Predictor (TP)............................................................................... 111 7.4.2. Flight Path Monitor (FPM) ............................................................................. 111 7.4.3. Conflict Probe (CP)....................................................................................... 111 7.4.4. Arrival Manager (AM).................................................................................... 112

7.5. 7.6. 7.7.

7.4.5. Negotiation Manager (NM) ............................................................................ 112 THE AIRCRAFT HMI ............................................................................................ 113 MAIN LESSONS LEARNT ....................................................................................... 115 GHMI DISPLAYS AND INTERACTIONS .................................................................... 115 7.7.1. Trajectory display (Dynamic Flight Leg Display).............................................. 115 7.7.2. TST ............................................................................................................. 116 7.7.3. Labels.......................................................................................................... 116 7.7.4. CRD ............................................................................................................ 116 7.7.5. HIPS............................................................................................................ 116

8. 8.1.

DISCUSSION........................................................................................................ 117
THE DESIGN PROCESS ......................................................................................... 117

8.1.1. The specification format ................................................................................ 117 -8Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI project, Final Report

List of Contents

8.1.2. The evaluation process..................................................................................118 8.1.3. Controller acceptance....................................................................................118 8.2.


HUMAN FACTORS ISSUES ......................................................................................119

8.2.1. Changing roles in teams ................................................................................119 8.2.2. Responses to high traffic loads.......................................................................119 8.2.3. Situational awareness....................................................................................119 9. 9.1. 9.2. 10. 10.1. 10.2. 10.3. 11. 12. 13. 14. 14.1. CONCLUSIONS ....................................................................................................121
THE DESIGN GOALS .............................................................................................121 CONTROLLER SKILLS...........................................................................................121

RECOMMENDATIONS ..........................................................................................123 FUTURE USE OF RE-CONFIGURABLE TOOLS AND GHMI.............................................123 ATM DEVELOPMENTS: AIRBORNE OPPORTUNITIES ..................................................123 AND THE FUTURE.............................................................................................123 ACKNOWLEDGEMENTS.......................................................................................125 GLOSSARY, LIST OF ACRONYMS .......................................................................127 RECOMMENDED LITERATURE............................................................................131 ANNEXES .............................................................................................................145 EXAMPLE OF GHMI SPECIFICATION FORMAT: THE ACTIVITY PREDICTOR DISPLAY .......147 14.1.1. APD | Description ......................................................................................147 14.1.2. Primary APD | Window characteristics ........................................................152 14.1.3. Primary APD | Window Content ..................................................................153 14.1.4. Secondary APD | Window characteristics....................................................154 14.1.5. Secondary APD | Window Content..............................................................155 14.1.6. APD | Dialogues / Managing the APD display ..............................................157 14.1.7. APD | Dialogues / Displaying / visualising filtered views................................165 14.1.8. APD | Dialogues / Using look ahead displays...............................................167 14.1.9. APD | Dialogues / Managing the PROSIT....................................................169 14.1.10. APD | Dialogues / Managing the PRORES ..................................................179 14.1.11. APD | Dialogues / Managing the PREPLAB.................................................181

14.1.12. APD | Dialogues ........................................................................................187 14.1.13. APD | Dialogues / Being informed of problem events ...................................192 14.2. THE INITIAL ROLE OF MAN DISCUSSION .................................................................194 14.2.1. Introduction ...............................................................................................194 14.2.2. Human Factors Contributions to Air Traffic Control.......................................194 14.2.3. Research Programme ................................................................................194 14.2.4. Conclusions ..............................................................................................197

DOC 99-70-02

Version 1.0 / August 1999

-9-

PHARE GHMI project, Final Report

This page left intentionally blank

-10-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Introduction

1.

INTRODUCTION The GHMI project was aimed at developing a next generation of controller working positions. It was part of the PHARE programme and was essentially tasked with the delivery of the Human Machine Interface or HMI specifications. This report will provide a historic overview of the projects as it developed over a period approaching almost ten years of work in the area. It started with a discussion on the role of man in future systems and the resulting overall design goals. Subsequently, the integration in the overall programme is explained and the adopted project structure. Issues basic to the work are discussed in some detail, such as Automation philosophies and the use of particular design methods. After presenting this background material, the results of exploratory experiments are discussed. These formed the basis for the actual design work pursued later in the project. The resulting designs are presented and their results reviewed. The report concludes with lessons learnt and recommendations for future work. The detailed design specifications are not a part of this report as they are too lengthy for inclusion. The reader is referred to the applicable PHARE documents.

DOC 99-70-02

Version 1.0 / August 1999

-11-

PHARE GHMI project, Final Report

This page left intentionally blank

-12-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

The Goals of the GHMI Project

2. 2.1.

THE GOALS OF THE GHMI PROJECT


THE HUMAN FACTOR

At the conception of the GHMI project, it could not be taken for granted that the socalled Human Factor would have to play a significant role in the future Air Traffic Management systems. The importance of the so-called Human Factor in determining the effectiveness and efficiency of ATC was more and more realised by users of the present ATC systems, but different ideas existed on the way forward. Technology seemed to have leaped forward in such a way, that some considered full automatic ATC as the way ahead, or even the best final solution for the Human Factor problem. Many international conferences, as an example the Advanced Study Institutes supported by NATO, discussed this issue and came to the conclusion that even full automatic systems would still suffer from the human factor, be it at a different level. Design, maintenance etc. would always involve humans and as a consequence issues related to accountability in case of unexpected accidents or incidents would occur. Details of such discussions can be found in the books: Automation and Systems Issues in Air Traffic Control (1991) and Verification and Validation of Complex Systems: Human Factors Issues (1993). A first discussion within PHARE was therefore directed towards deciding on the Role of Man in future ATM. This work was performed by an ad-hoc group of subject matter experts. They concluded that the application of Human Factors was indeed considered important but that funding and resources were not always in place. The US national Plan for Aviation Human Factors was an example of a commendable initiative that was widely discussed and supported but in the end not heavily supported by actual funding. One reason perhaps was that Human Factors used to be studied particularly by the academia while the development of new systems is strongly dominated by industry. National research establishments play an important role in bridging possible gaps and the PHARE programme represented a wonderful opportunity to break such borders, as it comprised a team of research establishments and ATC providers. 2.1.1. The starting points The role of man was therefore soon recognised and the following recommendations were formulated as a starting point by the role of man group: HUMAN FACTORS OBJECTIVES Human factors should be applied throughout the PHARE programme. The objectives are to realise the success of PHARE, the safety and efficiency of its final products, to optimise the roles within it; to ensure that human and machine are correctly matched and mutually supportive; to confirm that the PHARE air traffic control systems will not harm those who work within them and to provide satisfying, productive and valued work for future generations of air traffic controllers. This implies that it is envisaged that there will continue to be significant full time work for controllers within the medium term and in the longer term also.

DOC 99-70-02

Version 1.0 / August 1999

-13-

The Goals of the GHMI Project

PHARE GHMI project, Final Report

ITERATIONS An iterative approach is envisioned in the application of human factors, with the level of detail at which the human factors issues are addressed remaining in line with the level of detail of designs and specifications as they progressively develop during system evolution.

SINGLE UNIFYING PROGRAMME The human factors contributions within PHARE need to be a single coherent programme which contains means to unify the parts of that programme with each other since those parts may be conducted with different resources, establishments and staffs. Methods, measures, constructs, 'experimental designs, traffic scenarios, specifications, equipment, forms of data, forms of computer assistance, display conventions, types and formats of input devices, knowledge, procedures, instructions and forms of training are all tools which properly applied, can contribute towards unifying the programme. At least several of these means of unification should be adopted throughout the programme so that the findings from each part of the programme can be interpreted in relation to the whole, and do not take the form of a series of unconnected items.

TEACHABILITY Given that there will be jobs for human controllers in air traffic control for a considerable time, it is essential that these jobs are sensible, make use of the relevant training, human knowledge and experience, and are acceptable to controllers themselves and to others. Wherever a new task or function or role for controllers is proposed, not only is it essential to ensure that humans can perform their assigned functions safely and efficiently, but it is also essential to ensure that the human functions are teachable and that appropriate training can be devised. In a programme of studies and evaluations it is important to recognise any aspects of controllers' tasks which were difficult to teach or which controllers did not perform as planned in order to make suitable changes in the future training and to confirm the teachability of the new functions.

PROBLEM-DRIVEN APPROACH A problem driven rather than a technology driven approach is advocated as the best means to deploy the limited human factors resources available most efficiently. The need to evolve from current systems is a practical necessity, but so is the need to define potential end states, so that when they have been achieved, this can be recognised. It is considered that in the earlier stages, the technological innovations and developments will primarily serve as support tools and the automation provided within PHARE would remain essentially human centred. Ultimately, it will be necessary to try and evolve principles for matching human and machine when both have attributes such as innovation, intelligence, adaptability, and flexibility. New options are becoming technically available in the (far) future. It is intended within PHARE to largely retain the existing team structures and associated team roles. This should mean that most of the mechanisms and functions currently fulfilled by teams remain significant unimpaired or unaffected within PHARE, but it is prudent to check and confirm this rather than to assume it.

-14-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

The Goals of the GHMI Project

ACCOUNTABILITY The legal implications of the role of the human in PHARE have to be addressed, because the reasons for certain facilities or for the form, which they take, are not primarily technical or human factors reasons but rather legal ones. To enable the controller to actually exercise the responsibilities for which he or she is responsible. This criterion should often be applied during the iterative process to ensure that no controller is ever in the position of having the legal responsibility, but no means to exercise it or insufficient knowledge to understand it.

HUMAN ERROR Where there are humans there is the potential for human error. A guiding principle must be to design the workspace from the outset to minimise or prevent the commonest errors and to ensure that any that remain cannot be concealed but must be revealed. This error trapping has to be linked to policies on how fault tolerant the system is, and on how far the ramifications of any human error or any machine fault extend. Often the human controller does not need to know the nature of a fault and its causes, but does need to know how far its effects extend, and particularly which facilities remain unaffected by it and usable as normal.

TASK ANALYSIS Some form of task analysis, including human information processing functions, is necessary for learning and understanding the role of the human controller in relation to the PHARE programme. This includes decisions on the controllers' picture, on the controllers' level of experience and on the controllers responsibilities. Task analysis as a technique has its limitations and has to be supplemented by other methods.

HUMAN-MACHINE INTERFACE The design of the human machine interface has a crucial influence on determining the role of the human controller within PHARE. Only the information displayed or made accessible to the controller is available for use by the controller. Other information, no matter how relevant it may be, can have no influence on human tasks. It is therefore vital, to define carefully all the information that may be needed and to make adequate provision for it to be available. Similarly the only actions which the controller can initiate are those for which some provision has been made in the specification of the input devices provided. The controller may devise an intelligent and innovative solution to a problem, but if the means to implement it are not provided, then that solution couldnt be adopted. The specification of the workspaces and the human machine interface in particular should also encourage considerable commonality across equipment and practices. Human factors criteria, in addition to those of technical reliability, suitability, cost efficiency, and expected benefits, should be applied to assess proposed forms of computer assistance for controllers, and to match them with human capabilities and limitations. These criteria must emphasise safety and performance, but should also include effects on teams, on observability, on human roles, and on human attitudes, including acceptability.

DOC 99-70-02

Version 1.0 / August 1999

-15-

The Goals of the GHMI Project

PHARE GHMI project, Final Report

As ATM and the roles of human controllers evolve, it may be that the traditional forms of representing traffic may no longer be the most appropriate for the new forms of air traffic control that will be required. More extensive computer assistance will tend to dissociate the human controller further from the aircraft under his or her control. It is an assumption and not a proven fact that such greater dissociation must be inherent less safe, and evidence may be needed to discover whether or not such an assumption can be justified. SIMULATION The human factors considerations on the role of man within PHARE envisage that real-time simulation must probably remain the primary investigative tool. Whenever possible, it should be preceded by supplementary laboratory studies on simpler simulations and should also be followed by operational or field studies to confirm and validate the real-time simulations. Simulations cannot provide valid answers to every human factor question, and their inherent limitations have to be acknowledged and circumvented. All research on human factors issues within PHARE should be genuine, in the sense that the outcome is not known in advance and that the findings of the research if valid will be implemented, even if they are not what was predicted or hoped for. In human factors work, the whole is always more than the sum of the parts, and this will apply to the PHARE programme and to the separate parts of it. The need to be able to interpret these parts in relation to each other is thus an indispensable feature of the PHARE programme as a whole. A more detailed discussion document of the Role of Man group is provided as an Annex to this report. 2.2.
THE FUTURE USERS

The users for the PHARE systems are essentially people who will live somewhere in the future. The exact time scope is depending on both the successes of the PHARE programme and the time needed for the development of industrial products, i.e. the real operational system with its finalised controller working positions. Based on this future perspective (formulated around 1990) the following factors had to be taken into consideration: The so-called baby boom after the Second World War has led to a certain age distribution in the eighties and nineties. This age distribution resulted in a relative high availability of persons who could apply for a job in ATC. Therefore selection ratios could be high and attrition during training could be counteracted by using a surplus strategy. Essentially, there was room for selecting and training the right stuff. The after baby boom effect however, will result in a lower total availability of persons and a different age distribution. Both younger and older persons could become or stay involved in the future ATC system. Given a lower availability of persons, compensation has to be sought and several strategies could apply. One is to reduce the number of persons needed by striving for full automation or high levels of automation. Another one is to keep persons in service longer than today. In any case, the requirements for a reduction of workload and increased trainability seem immense.

-16-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

The Goals of the GHMI Project

Another issue is that the future users will become more computer literate, implying that the experimental systems developed now, could be totally obsolete when the next generation of computer systems is quite more advanced. Those could routinely include speech and intent recognition, dynamic scheduling of tasks and responsibilities etc. Therefore, design goals should not be too modest in order to gain acceptance of the present generation of controllers. In order to gain acceptance, additional work is anticipated in order to train present day users to the level of computer literacy expected in the near future.

So, the general expectancy was that more females would (have to) enter ATC, as well as older controllers who (had to) stay in service. Therefore, the design was planned to aim more at the average person in an attempt to reduce possible future needs for extremely experienced controllers or special aces. 2.3.
STATE OF THE ART

This section will briefly describe some of the major starting points for the GHMI project. At the time of its initiation, the state of the art was essentially represented by the results of projects like the EUROCONTROL project ODID III, introducing and exploring the concepts of windowing and the full use of colour. Other partners in Europe were also exploring the use of new display capabilities, especially the Sony, 50 cm x 50-cm full colour screen. Next to a discussion on colour, the issue of electronic flight strips or not, was a hot one. In the USA, a Centre Tracon Automation System was under development aiming at integrating trajectory negotiation etc. That program was highly technology orientated and did not include a strong HMI part. Full automation, through the use of the data link still seemed quite attractive at the time, leading to fully automatic versions of CTAS in the USA as well as in Europe, as pursued by the so-called ARC 2000 programme. It was also the end of the advent of Commercial off the shelf solutions, as enormous difficulties were encountered during software development and modification, as in the FAA program on its Advanced Automation System (AAS). Also programmes like AERA 2, that followed a technology driven approach with elements leading to expelling the controller in the end, were under fire. The risks for failure seemed too high to be realistic solutions for the foreseeable time frame. So, there were opponents and proponents for both a technology drive and a more human driven approach. The problem was how combine both in order to allow controllers to work more effectively and pleasurable, while still realising an increase in capacity. Or, as one of the future directors of Eurocontrol summarised it in 1993(!): Despite new information and telecommunication technologies, no ATC project has ever been proven to be feasible and also to increase capacity (Garot, 1993).

DOC 99-70-02

Version 1.0 / August 1999

-17-

The Goals of the GHMI Project

PHARE GHMI project, Final Report

2.4.

DESIGN REQUIREMENTS

Within the overall PHARE programme, several projects were running in parallel. All these projects had to deliver specific deliverables in support of the overall programme goals. The GHMI programme was not only intended to cover the Human Factors considerations into the design, but had to deliver a concrete product as well. The task assigned to the project was to deliver the design of the Human Machine Interface. In the end, GHMI software was required to run the simulations. The production of that software was not a part of the GHMI project. This type of task sharing was clearly unfamiliar to most of the participants in such a technical project, and many discussions were required to harmonise the overall project plans. Due to the historical background, the design goals of the GHMI project had to be a bit schizophrenic from the start. On the one hand, there were already software tools under development that had to be made usable for the controller, as full automation did not seem achievable with a high level of certainty. The automation philosophy of such tools were not directly user driven but clearly technology driven, taking the opportunities provided by data links and the availability of more advanced computing facilities. So, all kinds of duties could be taken from the controller without knowing if that strategy would still result in a workable environment for these controllers. One point was however, clear at the time. Controllers were too busy now and somewhere, somehow, some spare capacity had to be created in order to allow the controller to handle more aircraft in a given time period. Therefore, the GHMI design had to focus on a reduction of overall workload (as compared with earlier systems) for most, if not all controllers of the future ATM system. Given the highly philosophical discussions at that time, strong opinions on the right way forward existed and many arguments were in place, being in favour or against certain road maps to future designs. Objective measurements seemed in order to provide the basic data to structure such discussions and guide the decision process. Experiments have a different goal as compared to demonstrations. The latter intents to display certain features while the first intents to research the best solution out of options available and based on objective criteria. The GHMI team was trained in defining and conducting experiments and served as advisors on validation issues and the set-up of the demonstrations. Later in the programme, a more specific project was defined to cover these complex issues (the Validation project). A summary of the GHMI starting goals is provided in the next figure.

The major goals of GHMI


I Design, specify and assist the development of
a more effective HMI Increase controller output Realise workable workload levels Optimise application of PATS tools II Provide empirical evidence of effectiveness Subjective acceptance + Objective measures!

Figure 1: Summary of major goals in the GHMI project specification.

-18-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Integration in the PHARE Process

3.

INTEGRATION IN THE PHARE PROCESS The GHMI project was one of the last projects defined within the programme. The reason for this was that it took some time to realise that there would still be an important role for the human operator in the future, and as a consequence human factors issues to be considered.

The PHARE Process

ATM CONCEPTS

SCENARIOS

ROLE OF MAN

AUTOMATION TECHNOLOGY

GHMI DESIGN

INTEGRATE DEMONSTRATE

Figure 2 Parallel lines of work in the PHARE programme. A Technical and a Human line, that need integration and harmonisation. So, there were already running projects and GHMI had to catch up. Two lines of work could be identified. The first line was technical and concentrated on defining operational concepts and the required automation technologies, i.e. the PHARE Advanced Tools Set (PATS project). The second line was the human line trying to define human roles and associated HMI design requirements. The process is depicted in Figure 2.

PHARE R&D structure


PATS GHMI OTHER

PD 1 PD 2 PD 3

Figure 3: The relation between individual projects, the long -term perspectives and specific common demonstrations, needing harmonised and complementary deliverables.

DOC 99-70-02

Version 1.0 / August 1999

-19-

Integration in the PHARE Process

PHARE GHMI project, Final Report

These lines of work had to meet somewhere and the demonstrations were a practical meeting and harmonisation point for the deliverables. So, each project worked on its long term goals and delivered specific products in support of targeted demonstrations on en-route, terminal area and multi-sector applications. These PHARE Demonstrations (PDs) therefore served to create specific deadlines to comply with as well as practical opportunities for implementing so-called design freezes. 3.1.
GHMI PROJECT STRUCTURE

The following project structure was adopted in an attempt to meet all objectives in both the technical and human factors domain. The first line of research addressed the effectiveness of particular automation principles or philosophies. An example of such a philosophy is to provide a controller with advice on what actions to take. On one hand, this could reduce the taskload theoretically, but on the other hand it can also impose an additional task in case the controller is still in full command. In that case, the advice has to fit the big picture and therefore needs mental processing. If the controller would simply have to accept, he/she would essentially be designed out of the loop. The second line of research was aimed at finding GHMI solutions for specific automation technologies or PATS software tools. So, before implementing harmonised products, exploratory studies were performed on possible HMI configurations. The third line of work was addressing the required products for specific, large scale demonstrations, i.e. the end deliverables of the PHARE programme. The latter part took most of the resources assigned to the GHMI project.

Project structure of GHMI:

General HMI automation principles

HMI for Advanced Tools (PATS)

Specific Controller Working Positions (CWP)

PHARE DEMONSTRATIONS

-20-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Integration in the PHARE Process

3.2.

THE DESIGN PROCESS

The design was planned to follow a standard iterative procedure, well accepted within the Human Factors domain. So, normal steps like scenario, function and task analysis were included in the process of a draft GHMI definition. After that, prototyping would be used to tailor and test the proposals for effectiveness and acceptance. Experiments would be used to compare different solutions on their impact on objective and subjective workload etc. After iterations sufficient knowledge and experience should exist to decide on the format and content of the final specification. The process is summarised in the next figure.

The project plan execution


Anticipated design process: GHMI definition Prototyping Evaluation and experiments Iterations Specification Host integration and development

Figure 4: The anticipated design process, with prototyping, iterations etc. in order to draft a final specification for implementing within the demonstrations.

3.3.

THE DESIGN TEAM

Within such a collaborative project, many partners participate with different backgrounds and specialisms. Initially, all GHMI members were involved in the design of a particular system, i.e. the PD1 reference and advanced systems. Later in the project, some overlap between several sub-projects projects, necessitating the formation of dedicated design and training teams. This set-up proved effective in achieving the deadlines and deliverables of the overall project. It is however, important to assure sufficient transfer of knowledge and lessons learnt. This was achieved by having members in a team with experience from prior work and common GHMI meetings when required. A project of this scale involved many well motivated and hardworking individuals. The following persons were involved: Design: CENA: Didier Pavet, Nathalie Debeler, Christophe Mertz, Joel Garron DERA: Peter Goilleau, Chris Kelly, Brian Hadford DLR: EEC: Fred Schick, Haralt Derkum Alistair Jackson, Isabelle Pichancourt, Emmanuele Jeannot, Daniel Tasset

NATS: Angela Lucas NLR: Herman Nijhuis, Suzanne Buck, Dennis van Touw, Andrew Porter (DERA contracter), Peter Jorna (project leader)

DOC 99-70-02

Version 1.0 / August 1999

-21-

Integration in the PHARE Process

PHARE GHMI project, Final Report

Training: NLR: DLR: CENA: Marian van Blanken, Jan Joris Roessingh, Bas Kuypers Andreas Hobein Didier Pavet, Caroline Chabrol, Joel Garron, Florence Fichent and Jean-Claude Vigier

The specific teams were a PD2 design team, a PD3 design team and a training team. The basic and exploratory studies were shared amongst partners.

-22-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Human Machine Collaboration

4. 4.1.

HUMAN MACHINE COLLABORATION


AUTOMATION PHILOSOPHIES

Within aviation many lessons were learnt on how to automate effectively or not. Taking the aircraft as an example, one of the major problems encountered was that flight crews lost track of what the automation was exactly doing, the so-called mode awareness problem. This applies especially to situations were the aircraft is on automatic and the crew is monitoring the situation. In monitoring situations it is difficult for humans to maintain a sufficient level of arousal and attention to respond effectively in case of unexpected deviations or disturbances of normal operations. Such events led to the discussion on human roles in future systems. Automation has most often addressed a particular function to could be automated with existing technology. A problem with such an approach is that it does not necessarily fit the normal line of events when working with the system as a whole. So, human task execution involves the use of multiple systems over time. If we take the flight deck as an example, navigation functions can be automated but the crews have to combine navigation with communication. As a result they have to shift between different systems with different characteristics or behaviour. Incompatibilities can occur with respect to ergonomics, leading to confusion and misunderstandings. In summary, a technical approach to automation is biased towards developing a system or box taking care of some function. A human centred approach is more directed towards the way people perform (series of) tasks and procedures, taking into account that more than one system or human operator can be involved in performing a human task.
Examples of some philosophies are provided in the next Figure.

Humans versus Machines


Problem extra traffic, flexible routes, free flight Options machine based ATC, exclude human bottleneck reduction for controller Strategy remove tasks Automatic allocate tasks Adaptable take charge Adaptive change tasks Advanced

Figure 5: Automatic: in this case a function is fully automated and no human intervention is anticipated, except in case of a malfunction. Tasks are taken away from the controller. Adaptable: in this case a function can be switched on or off at the discretion of a controller. Tasks are allocated to either machine or human depending on factors such as traffic load, number of controllers available etc.

DOC 99-70-02

Version 1.0 / August 1999

-23-

Human Machine Collaboration

PHARE GHMI project, Final Report

Adaptive: in this case its a second layer of automation that decides on the configuration. If traffic load is increased, or the controllers level of workload is relatively high, more automation is made active. Advanced: in this case no existing task or function is automated, but technology is used to modify a task, or create a totally new one.

4.2.

THE TOOLS APPROACH

Within PHARE, the initial approach was biased towards the automatic concept. As a result, the project specification named developments of automated functions like: a trajectory predictor, the conflict probe, a problem solver and a flight path monitor. Later, it was realised that such functions would still be under control of a human controller. To emphasise the human aspect, a tool approach was promoted. An advantage is that a system can be equipped with many provisions and tools tailored or modified to be compliant with the controllers needs. Many system configurations are now possible, while re-using the same essential technology. The word Tool suggests and implies that a controller has some control over using it or not. So, the automation configuration will be adaptable to the needs at hand. Some of the tools developed never existed before and created new type of tasks for the future controllers. So, technology was used to create more advanced tasks. Routine tasks, taking time but not requiring strategic thinking, were fully automated whenever feasible. Data link communication replacing radios is an example. After essential decision making, a software communications manager is capable of informing the aircraft fully automatic. An important advantage of such a comprehensive approach is that a system can be reconfigured in many ways, without discarding the expensive technology or software development. So, a PHARE system can be modified easily to be adaptive in response to a psycho-physiological workload index obtained from a controller. The approach taken in design was to integrate as much tools as possible into one generic working position. This allowed experiments to assess the spontaneous use of some tools without forcing a particular working method on a controller. Only in very specific controller working positions, unique tools were added. After gathering the data, final configurations and working methods can be defined, resulting in more validated configurations that can be build more cost effectively.

-24-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Human Machine Collaboration

4.3.

TASK AND SKILL ANALYSIS

Often the wording tasks and skills are used interchangeably, but there is a distinct difference. Performing the same task like hammering a nail in a piece of wood under different circumstances can involve totally different skills. Imagine hammering in the open air (no problem for most people) as compared to hammering under water by a diver (wood floats and it is a bit dark). All is the same, except the environment and suddenly something simple becomes very complicated. Similarly, the task of landing an aircraft requires different skills when performed under bad weather or night, or when it involves severe cross winds. In addition to these factors, time restrictions play a role in determining the required level of skill. When landing a general aviation aircraft, completing a circuit and performing down wind checks with a slow aircraft requires different skills, or levels of skills, as compared to a fast aircraft. If the circuit cannot be extended for noise abatement reasons, time pressure will be imposed on all the checks and communications required. Planning and anticipation are suddenly even more critical as the are normally. As a rule of thumb, a skill can only be defined if: the task to be executed is known; the working environment and context, including other tasks, is known and the timing pattern required is known.

Often training requirements seemed to be based on tasks for the overall system in stead of the skills required for the human operator. One reason for this bias is the complexity of identifying human skills as opposed to the relative ease of defining operational tasks for the system. In general, there are two major methods to analyse human tasks and skills depending on being pro-active or re-active: Theoretical or analytical analysis: most often used when the system is not yet in service or is being updated. Based on available system and mission scenarios descriptions, anticipated skills are identified and the training is prepared. Empirical analysis: most often applied when the system is in service and problems are encountered with respect to attrition rates, performance levels and or selection issues. By observing and measuring actual performance (strategies) new knowledge is acquired on the real skills and the causes of the training problems. Within ATC many video sessions have been used to investigate the strategies and skills of controllers.

DOC 99-70-02

Version 1.0 / August 1999

-25-

Human Machine Collaboration

PHARE GHMI project, Final Report

Operational analysis

Operational requirements Mission analysis Function analysis Function allocation


System and HMI design

human human tasks HMI designs

automation software specifications

procedures time line working environment context skills training & selection
Behavioural and workload studies

Figure 6: Overview of the analysis processes that are involved in both System design, Human Machine interface development and the identification of critical skills to serve as inputs to the training (and selection) procedures. Note that the wording scenario has been
omitted in order to prevent confusion. Normally, it is used by operational analysts in the block mission analysis and by behavioural analysts in the block procedures.

The first theoretic approach uses the familiar methodologies derived from Mission and Task analysis as used in military system design. Based on insights on the characteristics of (future) systems, environmental context(s), tasks to be performed by the human operators are defined. After combining the tasks with their contexts, skills can be identified, clustered and grouped into training tasks (meaning the particular combination(s) proposed to facilitate training progress). The second method is more practical and uses observations and studies of human operator behaviour while performing their work in reality. The advantage of the latter method is that the environmental context is actually present, so critical interactions and features can be defined or even measured objectively. The estimated working conditions need to be considered very carefully in the theoretical approach as they will impact on the particular difficulties that the human operator will encounter and by that have a strong influence on the real skills involved in successful operations. Team factors are often overlooked.

-26-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

Human Machine Collaboration

The methods mentioned are often leading to confusions about what task analysis is all about and for that reason a short overview is presented. The aforementioned procedures are not to be considered as mutually exclusive, but as complementary. They are both part of a more comprehensive overall methodology, which is also applied for other purposes like the design process of the system itself. Part of this process is the design and specification of the Human Machine Interfaces needed. So, ideally, there should be a lot of information available that could be re-used for the training design. However, in reality, designs are often driven by technology applications and no detailed Human centred design has been accomplished. Therefore, the specification process should be able to handle all the steps required. These steps are illustrated in Figure 6 that represents an amalgamated view on many different, but quite complimentary analysis techniques. Within this analysis, the specification is of the generic type for a long time. With generic we mean that the obtained specified elements like the tasks identified are still not specifically related to an individual. The problems start to occur the moment that the individual operator strategies and the resulting variations in human performance levels have to be considered, i.e. effects of practice, experience, individual abilities etc. The creation of a so-called time line implies a specification of which tasks have to be performed at what time and it what order. So, essentially working procedures are specified. In reality, it is well known that persons will take shortcuts, invent new strategies etc. Predicting for instance workload levels is very hard when these strategies are not considered or still unknown. So when defining the skills required, possible variations in human behaviour strategies have to be considered and when possible, tested in prototypes. This kind of data is hardly ever available, so with good reason, training factors impose a clear emphasis on addressing the characteristics of the trainee (future users) and on the consistency of the training required. Both of these elements are not present in the above illustrative model and form a unique feature of training analysis. A major issue encountered in the programme, was the uncertainty about the operational procedures. The Operational Task force (OTF) had great difficulty in defining a commonly agreed working procedure. Therefore, the GHMI team had to invent such procedures based on capabilities of the tools and characteristics of the GHMI. This made the iterations more complex as compared with a situation were the major ATC working procedures would have been available. 4.3.1. Task-logic diagrams Objective: The objective of the Task Logic Diagram approach is multiple. It enables a logicaltemporal description of the possible future working activity (or dynamic aspect of the task) of the controller and the involvement of other controllers, in other words the task sharing. Note that other actors such as pilot or supervisor may be mentioned as interlocutor. The interest of this formalism is to be open and to enable different dimensions of description.

DOC 99-70-02

Version 1.0 / August 1999

-27-

Human Machine Collaboration

PHARE GHMI project, Final Report

The TLD approach can support the whole process from the Task Analysis to the HMI specification. In an early phase, the TLD do not yet refer to any HMI, it is only in a later form that Tasks are described from a HMI point of view. Hence, an HMI input could be a controller action (i.e. using the mouse) and an HMI output could be a display of information such as an updated trajectory. System processes (i.e. processes performed by the system but not by the HMI) are mentioned in a high level format, while the detailed descriptions of these processes were the responsibility of the software design teams. One of the interests of such a multi-dimensional description of the task/human activity is in its possibility to show the flexibility of the HMI in case the same task may be achieved via different procedures using different HMI facilities or tools. Another interest of TLD is in its ability to give a view of the complexity of the task, via its type of structure (i.e. sequential, parallel), its number of tests required, its number of processes/actions required, etc.. After selection of the route through the HMI (interface navigation), a timeline can be constructed to study bottlenecks, inconsistencies etc. Each diagram takes the form of a flowchart referring to the overall processes performed either by the HMI, the system or by the controller without the system. (An overview of the TLD formalism will be discussed shortly). Planning: A first set of TLDs was delivered during the Task Analysis Phase carried out by the GHMI Design Team in 1996 (GHMI Specification for PD3 - Part 1 -PD3 Controller Task Logic -August 96). In the final and complete version delivered as Annex B of the GHMI Specification version 2.2 (January 98), the detailed activity was described for the following different ATCO played in PD3 in the Advanced Organisation:

En route Multi-sector Planner (MSP) En Route Planning Controller (ER PC) En Route Tactical Controller (ER TC) Departure Planning Controller (DEP PC) Departure Tactical Controller (DEP TC) Arrival Sequence Planner (ARR SP) Arrival Tactical Controller (ARR TC) ( i.e. TC of the 3 initial (INI), intermediate(ITI) and final approach)

The Operational Task Force group (OTF) had produced a description of the roles and intended tasks for the controllers. This served as a major input for the GHMI PD3 Design Team and intensive collaboration was established with the PD3 OTF. When the OTF agreed on the overall procedures, the TLDs were produced jointly with In house Operational experts of each centre. It was intended to be a Living document. The content was refined as the GHMI specification evolved up to the version 2.2 (before the demonstration started). Ideally, as the final PD3 GHMI specification, the TLD document would have been updated at the light of the final demonstration result. It has to be reminded that in addition to the HMI, the working methods are part of the validation process. The pertinence of a new operational concept relies as much on the task sharing among actors as on the HMI adequacy to the task. Overview of the Formalism:
-28Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI project, Final Report

Human Machine Collaboration

With the formalism used, the HMI is considered as an object with two sides: the User side and the System or Applications side. From each side what comes in and what goes out is shown by the direction of the triangle relative to the HMI itself. The boxes with an ellipse inside represent the User side; the boxes with vertical lines parallel to the box sides represent the Application side. (Note that a box with nothing inside (except text) shows that this activity does not imply the use of the HMI, e.g. the direct communication from the Controller to the Pilot by R/T. (Figure 7).
HMI

Trajectory Edition

STCA is displayed

CP detects a urgent conflict

TP computes new trajectory

USER
CP : Conflict Probe, TP : Trajectory Predictor , : Output

SYSTEM
: Input

Figure 7: User / System division in the TLD specifications

DOC 99-70-02

Version 1.0 / August 1999

-29-

PHARE GHMI project, Final Report

Human Machine Collaboration

Illustration: Description of the Task of Trajectory Edition

Level III ER
Edit Trajectory via TEPS
Subordinate Task

Add or manipulate Time Constraint in RPVD or Profile window

Start

Activate TEPS on required aircraft

Select appropriate Trajectory via TST

Display chosen trajectory in RPVD TEPS & Profile window

Add or manipulate route constraint in RPVD

Validate Wtraj via TST

Add or manipulate Altitude constraint in Profile Window

No Display : -TPgenerated Trajectory - conflicts in the TEPS (RPVD & Profile) - need of ccordination in the TST CP generate conflicts on TP generated alternative traj NM generates status on need of coordination

END

Yes

Is Wtraj Satisfactory?

TP generate trajectory using TEPS constraints

OC 99-70-02

Version 1.0 / August 1999

-31-

PHARE GHMI Project, Final Report

Human Machine Collaboration

A user command is an input from the HMI user side, the display of data is an output of the HMI User side. A user command always provokes a display of data. With certain functions, the process is only within the HMI User side e.g. a zoom of the Radar Plan View Display. Otherwise most of the functions imply the processing of data by a part of the ATM Software Application. The HMI System side carries out the dialogue of the HMI with these processes. A user command provokes a call to a specific data process, it is an output of the HMI Software System side, e.g. when the PC edits a trajectory, the Edit Command requires the use of the TP. (Trajectory Predictor). When a data process works continuously, as the STCA (Short Term Conflict Alert), it provokes a call to the HMI System side to ask the HMI User side to present/display the process output to the controller. Note that the way data is processed and which part of the software application is responsible for this processing is not always evident, especially for non-software specialists. Consequently, at an early stage of the specification process, the description might be rendered only in terms of data and processes carried out by the HMI User side. The aim of the specification process is the definition of the best possible interface from the user point of view. Following this objective, human activities (and requirements) will, initially at least, be more detailed than those for data processing. At a later stage, if some limitation in term of data process, or in terms of integration of data from different processes is identified, it may be interesting to show this explicitly in the schema. For example, different tools assisting the Trajectory Editing can use different TPs so the output presented to the user may be different.

Activity without any link to HMI application

HMI User side (Link between HMI dialogue and User)

HMI System side (Link between HMI Dialogue and ATM application)

Figure 8: Different types of dialogue

Note that the HMI User side will be specified in as much detail as possible but the Software Application side will be treated as a black box. Its detailed description is under the responsibility of the PD3 Software design team.

Lesson learnt (advantages and drawbacks)


In order to complete the TLDs, it was originally intended to describe each task in terms of a Task Description Form defining the actor(s), goal to be reached, information processed (e.g. input and output), triggering and stop conditions, properties such as priority, Back/ foreground task, etc In practice, the result of the task description was directly embedded into the GHMI specification either in a specific chapter defining main tasks such as Ground Ground Co-ordination or Air-Ground Negotiation, etc (e.g. PD3 GHMI specification V2.2 - Chapter 2) or in every tool window display and dialogue description. The Task Description should generate the system function requirement that serves as input to the PATs software team defining information and processes required. When the task analysis started, most of the tools were already specified and even implemented. The GHMI DT had to understand from the documentation available whether the user requirements were compliant with the task analysis. This was followed by endless adjustments between operational and technical requirements.

DOC 99-70-02

Version 1.0 / August 1999

-32-

Report Title

Chapter title

Additionally, with so many specifications (i.e. about ten CWPs to be designed in both Baseline and Advanced Organisation) it seemed necessary to have a Matrix of Objects emphasising the commonalties and specificity of every operational data structure across the HMI, e.g. a trajectory, a conflict etc.... Such a matrix was planned. From a technical viewpoint this would have enabled a better understanding between PATS and GHMI and a better tools integration. In the absence of feedback from the PATS people, the use of TLD as an input for the normal software oriented user requirement document completion can not be considered as proven yet. TLD utility and usability for the software team has certainly to be improved. A better interface with software developing methods would improve the efficiency of the overall design. However, the TLD techniques have been effectively used in support of: Training material development Analytical Workload Analysis via PUMA techniques (see PUMA ANALYSIS REPORT by NATS).

Without any doubt, PD3 TLD can be re-used as a starting-point for further research. The full benefit of TLD would be in a more software-supported version allowing dynamic simulation and easier navigation, coupled with Task Description Form management. Given the constraints in planning and how work was allocated across the GHMI DT partners, specialisation was inevitable. Consequently, extended and systematic crossvalidation within the OTF team and with external operational experts did not always occur. For a more harmonised European HMI, much additional work must be undertaken.

DOC 99-70-02

Version 1.0 / August 1999

-33-

PHARE GHMI Project, Final Report

Results

5. 5.1.

RESULTS
EXPLORATORY STUDIES

The aim of exploratory studies was to gain practical experience with some HMI features and facilities that probably would become a part of the final design. As an example, in this stage of the PHARE GHMI project there was still a lot of (public) discussion on what input devices had to be preferred and for what reasons. Also the use of cockpit and ATC data links were studied in many national and international projects. Also the use of advisories was under discussion as there was a possibility that such presentations would change the type of skills needed or could even represent additional work for a controller handling high traffic loads. It was therefore essential to acquire some background data to assist the harmonisation and decision making of the following integral design process. Some of the results, for instance on input devices, may be superseded by more recent material. They are still mentioned for historic reasons and to provide some background on why some design selections were made. 5.1.1. Input devices Introduction The aim of the DERA study was to compare the speed and accuracy of various mechanisms of inputting data in an ATC system. In the light of the above it was decided to carry out an experiment comparing four input devices: mechanical mouse; track ball; digitiser pad with puck; digitiser pad with stylus.

The mechanical mouse was chosen because of its wide use in computer systems. An optical type of mouse was not used because of the disadvantage that the surface has to be very smooth and reflective and is subject to wear and tear. The speed and accuracy of input are also affected by the input mechanism on the screen, and the a following mechanisms were compared: Scroll menu: To make an entry on the scroll menu the user clicks on the selected value. To scroll up or down by five values at a time the user clicks on the arrows at the top and bottom of the menu. Press and drag menu: to make an entry on the press and drag menu the user releases the mouse button over the selected value. To scroll up or down by one value at a time the user drags the cursor over the arrows at the top and bottom of the menu. Virtual keypad: To make an entry the user clicks on the appropriate keys shown on the keypad. Elastic vector. To make an entry the user drags the end of the vector round to the direction of the required heading and releases the mouse button.

DOC 99-70-02

Version 1.0 / August 1999

-34-

PHARE GHMI Project, Final Report

Results

Figure 9: Input mechanisms for the experiment Experimental tasks

The participants were asked to enter a series of flight levels and a series of headings using each of the above input devices and input mechanisms. The aim of the experiments was to assess speed, accuracy and ease of use of the input devices and mechanisms. Two menu default options were considered for altitude entry as follows: The menu pops up centred on the current cleared flight level, with the cursor on this value. This option models the safety approach in which an inadvertently entered new flight level will be the same as the current flight level by default and the system will remain in its previous state. The menu pops up centred on the exit flight level, with the cursor on this value. This option models the efficiency approach, in which it is assumed that a controller will most likely clear an aircraft to its exit flight level if possible. Hence the speed of the input action is increased when the menu is defaulting to the appropriate value. Implicit selection: the selection button is automatically selected when the cursor moves onto the button. Explicit selection without visual feedback: A mouse button has to be pressed when the cursor is over the button to select it. The button is not highlighted as the cursor enters it. Explicit selection with visual feedback: A mouse button has to be pressed when the cursor is over the button to select it. The button is highlighted as the cursor enters it, thus indicating the acquisition of the button. Results
DOC 99-70-02 Version 1.0 / August 1999 -35-

Finally three different types of selection were used: -

Results

PHARE GHMI Project, Final Report

The median time for each device for each entry value was first obtained. Using the median rather than the mean, reduced the effect of individual values which cause problems, for example where the participant took several attempts on one occasion to enter a value, then mean time would be excessively high for that value. The numbers of errors was very low as illustrated in the following table. Errors (nr.) Errors Inputs Mouse 11 800 Trackball 13 800 Puck 6 800 Stylus 18 800

The next table shows the median results for the time taken to press the selection button (tsb) with different button sizes. The smaller button and the track ball both appear to result in longer time being taken to press the button. The other three input devices all result in approximately the same median time to press the button. Timing (sec.) Small button large button Mouse 1.96 1.83 Trackball 2.89 2.53 Puck 1.96 1.80 Stylus 1.94 1.74

Comparison of input mechanisms

As with the comparison of input devices, the median for each data value over all participants was obtained: scroll menu; press and drag menu; elastic vector; virtual keypad.

-36-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Figure 10: Effect of input mechanism on time to enter a heading value. For menu mechanisms, the action of scrolling up or down the menu may or may not be needed, depending on the entry values. This extra action has a major effect on the time taken to select a value. This accounts for a steep rise in all menu-timing results. The press and drag menus scrolled up or down one-step at a time, so the entries where the new value was close to the original, required fewer steps than those where the new value was remote from the original. In each case heading(s) were being entered, using explicit selection with visual feedback, small selections buttons and the menu centred on the current heading. The Figure shows that the elastic vector was slower than other mechanisms. There are two possible explanations for this, one applies only in this study, the other to all elastic vectors used for heading input. In this study, due to time constraints, only one out of 20 conditions used the elastic vector. Participants may not therefore have become as familiar with the mechanism as with other mechanisms. The second possibility is that the dexterity required to drag the end of the vector round to the appropriate angle is greater than that required moving the cursor down a menu or over a keypad. There are several sharp peaks and troughs in curve for the elastic vector results, showing that the time taken to enter a value is affected by the value being entered. This is explained as follows: a peak in this median curve indicates that all participants took a longer time to enter this value than those around it. The results where elastic vector was quicker are probably those where the distance the vector had to be dragged was small, i.e. the new heading was close to the current heading.

DOC 99-70-02

Version 1.0 / August 1999

-37-

Results

PHARE GHMI Project, Final Report

Conclusions

One conclusion was that the track ball (note that different types are available with other characteristics) was slower than other devices, both in moving across the screen to a small target and in entering a flight level from a menu. The experiment yielded very few errors; therefore there was no perceived difference in accuracy between input devices. The menu appeared to be the best mechanism, however, the dramatic increase in entry time associated with scrolling the menu shows the importance of avoiding scrolling by intelligent centring of menu when it pops up. Based on such exploratory studies, it was decided to select the mouse and the menu formats for further prototyping. The mouse, because of its increasing user familiarity and easy availability. A trackball has certain advantages for more operational systems, like maintainability, robustness etc. but it needs careful calibration to obtain a good balance for larger and smaller movements. 5.1.2. Gesture recognition As a future alternative to menus etc., an experimental technique was explored by CENA that would allow the controllers to write their inputs. So instead of selecting from a menu, signs and commands could be written. With such technology, writing on strips could be theoretically possible if desired. The GRIGRI study (Gestures, Recognition on Interactive Graphical Radar Images, French for scribble) addressed this option. The goals were to evaluate: the usability of 2D gestures recognition for ATC performance of the recognition software effectiveness of chosen gestures, learning time and memorisation the ergonomics of an integrated display with gesture control

The HMI included a command panel with large buttons for finger tip use, gestures for radar image management (zoom, pan), gestures for flight labels and fields and gestures for numerical inputs. The results of controller evaluations were unexpectedly positive. Gestures were rated as more natural and less demanding than mouse inputs. Users were sceptics at the beginning, but after twenty minutes (!) of use they all felt confident and cool. Due to time restrictions in the programme, further investigation was halted, as gesture technologies were not foreseen for implementation at the medium term. The technique seems promising for future application. 5.1.3. Controller data link interface Datalink communication in this NLR study can involve computer-computer interfacing as well as Air- Ground human operator communications. Pilot can request route changes, ask for information etc. while the controller can detect possible conflicts in the future and provide the aircraft with instructions. Finding and implementing a resolution in the present day systems often requires vocal communications with the pilots as well as inputting data (the instructions) into the ATC computers in order to display the overall status to the controller.

-38-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Pop-up menus for single and multiple on screen inputs


SPD
button

Send s 370 360 350 340 330 320 310


plot symbol

FL

SPD

WP send

HDG

040

KLM123 153 120 100 402 280 250 B747 045 010

370 360 350 340 330 320 310

370 360 350 340 330 320 310

SPL HST HEL

scrolling

Figure 11: Examples of data link user interfaces that allow direct selections and transmissions of solutions of problems and instructions to the aircraft. A data link user interface can accommodate both these functions at the same time. In an experiment, different versions were developed and implemented for testing under high and low traffic loads (Hooijer & Hilburn, 1996). The data link can be implemented as a separate communications window on the controllers display or as an integrated part of the so-called radar plot symbol that is associated with a particular aircraft. Examples of such selectable pop-up menus are depicted in Figure 11. Similarly, the feedback of actual status of the negotiations with the aircraft need to be provided as data links have a time delay in transmitting the data, depending on the particular medium used i.e. radio frequencies, radar signals etc. The feedback can be provided through different means. Integrated with the radar plot data block or as a separate communications window. Examples are shown in figure 3.

DOC 99-70-02

Version 1.0 / August 1999

-39-

Results

PHARE GHMI Project, Final Report

Feedback of datalink status


KLM123 s 153 120 100 s 402 280 250 4 B747 045 010 6 = uplinked (green) = no response > 30s. (red) = acknowledged (green) = unable (red)

plot symbol

Figure 12: Examples of means for providing feedback on the data link status for communicating and receiving confirmations from many different aircraft. From these options three combinations were designed that will be designated as user interface combinations A, B and C. The mapping of the particular features that were combined is as follows: Condition A B C Input method pop-up menus pop-up menus combined pop-up menu Feedback DSP label symbols label symbols

The conditions A, B, and C were intended to represent an increasing level of integration of task elements and feedback onto the screen of the Air traffic controller. The higher level of integration lowered the number of on-screen actions and facilitated the subsequent integration of data and information. These options have different disadvantages. As an example, the data link status window will change in content (ir-) regularly, thereby attracting the controllers attention at a time that such information would not strictly be required for mental processing. Alternatively, the pop-up or better, pop down menus of the radar data block can obscure some of the other traffic data, although at a moment selected by the controller who decides to take an action. The experiment used the following measurement techniques: Eye point of gaze measurements, head tracking, pupil size, heart rate and respiration, heart rate variability, logging of system inputs and responses and extensive use of subjective ratings. The subjects in this experiment were, like in the cockpit data link study, normal professionals, and in this case regular controllers. The results showed the following:

-40-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Heart rate variability is a workload sensitive measure that normally decreases when people are working under conditions that are cognitively loading or stressful (for a review see Jorna 1992). So a user interface that is easier to work with could result in a relative increase as compared to more cumbersome interfaces. However, no very explicit results were expected, as Heart rate variability is especially sensitive to the more extreme overall working conditions that are associated with particular distinctive mental states as associated with mental work and stress. The results obtained in this experiment proved very promising as indicated in Figure 13.

Objective measures: Heart rate variability


5.8 0.1 Hz component 5.6 5.4 5.2 5 4.8 4.6 4.4 4.2 A B C Low High

Figure 13 Heart rate variability increase (indicating less effort) as a function of controller data link interface and traffic density (Low or High).

Objective measures: Pupil size


4 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3 A B C

Size in mm.

Low High

Figure 14: Pupil size decrease (indicating less effort) as a function of controller data link interface and traffic density (Low or High). The impact of traffic density on heart rate variability is quite consistent and also distinct for type of user interface.

DOC 99-70-02

Version 1.0 / August 1999

-41-

Results

PHARE GHMI Project, Final Report

Another objective measure explored was pupil size. Normally, the pupil will open up, when more visual information has to be processed mentally. So, as an experiment, the pupil size was calculated and analysed. The results of this analysis are depicted in the Figure 14. The size of the pupil(s) is also modified by physical factors like the amount of light present, but visual information sampling and mental processing of visual data also influence it. In that case, its size will increase as a function of the amount of visual information processing. With more light, it will decrease. The results indicated that accurate measurements of small differences in size could be realised. Similarly to the heart rate variability data, the workload as indexed by the pupil decreased in size as a function of integration in the data link interface. It increased markedly with an increase in traffic density (difference between Low or High traffic samples). Note that more traffic implies more radar plots on the screen, which should tempt the pupil to downsize as a function of amount of light in the display. An example of the subjective ratings provided by the controllers is summarised in Figure 15.

Subjective measures: NASA TLX


8 7 6 TLX score 5 4 3 2 1 0 A B C Low High

Figure 15: Ratings provided after the experimental sessions as a function of controller data link interface and traffic density (Low or High). The subjective ratings displayed a marked sensitivity to the amount of traffic present, but revealed a quite less spectacular difference between user interfaces. So, in this experiment the objective results all pointed to the possibilities of designing effective controller data link interfaces, but the subjective data did not reflect this to the same extent.

-42-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

5.1.4. Conflict detection and resolution tools The mental processing capabilities of the air traffic controller are generally considered to represent a major bottleneck in expanding the amount of air traffic. One reason is the communication process that is of a serial nature and has to address each plane individually. Also, the controller has to build an overview over the traffic streams in order to be able to predict and anticipate possible separation issues. In case of a possible overload, the traditional procedure is to subdivide more sectors so more controller teams can share the work. The disadvantage is of course that the communication requirements also increase dramatically, thereby limiting the overall effectiveness. Alternatively, the use of data links allow the controller to issue messages to both aircraft and other centres and both individual aircraft and groups of aircraft can be addressed if relevant. Also, clearances with multiple parameters or complete route instructions can be issued. Software tools can provide assistance in conflict detection and resolution of aircraft route or altitude infringements. The effectiveness of such possible assistance was investigated by means of simulations and extensive objective and subjective measurements (Hilburn et al. 95, Hilburn et al. 96). The results of a comparison of a stepwise increase in the level of assistance provided with a manual baseline are depicted in Figure 16 for pupil size measurements.

Effect of automation on pupil size


1.0

Low traffic High traffic

Pupil diameter (Z score)

.75

.50

.25

Manual

Detection

Resolution

Figure 16: Pupil decreases as a function of higher levels of automation assistance. The data obtained in this study seem very promising for extended applications of these measures. Also, the results for Heart rate variability revealed an almost identical trend with heart rate variability increasing systematically when more assistance is provided to the controller. An additional technique applied was the principle of dual tasking but with the purpose of acquiring an objective measure of situation awareness, in this case defined as awareness of communication and aircraft status. Incidentally, aircraft would fail to acknowledge theyre up links and the controller had to detect these occurrences. In case of a reduced overall task load, more options are present to perform this particular task more timely. The results are depicted in Figure 17.

DOC 99-70-02

Version 1.0 / August 1999

-43-

Results

PHARE GHMI Project, Final Report

Detection of unconfirmed uplinks


Response time (seconds)
50 low traffic high traffic

40

30

20

10

Manual

Detection

Resolution

Figure 17: Controller response times to status information on communications and aircraft responses. Apparently, the tools do allow the controller to scan the display more effectively, resulting in better overall performance. So, overall the objective measures clearly indicate the potential of the tools in helping the controller. But how do the controllers rate them subjectively? That data is depicted in Figure 18.

Subjective workload ratings


20 15 10 5 0
Manual Detection Resolution

high traffic low traffic

Figure 18: Controller estimates of workload effects as a function of more software tools. Surprisingly, the controllers rate the effects of the tools quite contrary to the picture provided by the objective measurements. Possibly, the addition of extra functionality is experienced as more work to be handled. Alternatively, their ratings may be influenced by the relative unfamiliarity with the automation. Essential is that subjective ratings can be influenced by many other factors than task loading alone.

-44-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

5.1.5. Arrival sequence tool A mediating factor in these ratings could be the particular strategy employed by the controllers in using these tools. Controllers have very particular strategies in handling their traffic and these controller methods could influence adaptation to the new controller working position. Analysing the eye scanning during high and low traffic density samples can provide an illustration.

ATC plan view display (PVD)


Time line

15

AMC 282

Hand-off
RIVER AMC 282

10

Traffic Datalink
05
IBE 326 IBE 326

Pre-acceptance

Figure 19: Display lay out of the Plan View Display with Arrival scheduler at the left, aircraft hand-off area and data link communication status panel. The areas are used by the point of gaze equipment to provide area related data on eye scans, durations, transitions etc. The present study (Hilburn et al 1995, 1996) investigated the human use of possible tools in a future ATC scenario with present (low) and future (high) traffic loading. Arrival traffic approaching Schiphol was displayed on a Plan View Display (PVD), see Figure 19. It contained: Timeline window the controller must monitor this area for scheduling information, if he/she is to ensure that the arrival sequence is as desired, and that ETA and STA agree; Traffic area the region of the screen in which controlled aircraft appear, including both the aircraft location plots, and the flight labels that display all relevant flight parameters; Data link Status Panel displays all recently-uplinked messages, together with elapsed time since transmission, and whether the clearance has yet been acknowledged by the aircraft; Hand-off region general area in which the PVD displays the plots and flight labels of aircraft around the time that they are handed off to Amsterdam approach (APP) control; Pre-acceptance region the general PVD region that displays aircraft before they are accepted from the previous sector. Viewing this region provides the controller an indication of impending traffic load changes.

The results of the point of gaze measurements are depicted in Figure 20.
DOC 99-70-02 Version 1.0 / August 1999 -45-

Results

PHARE GHMI Project, Final Report

gazes / min. (avg. dwell, in ms)

gazes / min. (avg. dwell, in ms)

7.8 (672.9) HO

9.0

(664.5) HO

7.6 (409.0) 15.7 36.7 (620.2) TL TRAF (584.3) D/L

1.84 (405.8) 14.9 44.6 (611.7) TL TRAF (604.7) D/L

4.9 (484.1) PRE-ACCEPTANCE

4.5 (546.7) PRE-ACCEPTANCE

Figure 20: Dwell time and fixation frequencies, for low (a) and high (b) traffic load. Comparing the results in Figure 20 gives an indication of how traffic load influenced the visual scanning of the task-relevant surfaces. It appears that average dwell times were slightly influenced by differences in traffic load. Surfaces 1,2, and 4 (i.e., the timeline, traffic and hand-off regions) showed a decrease of 0.8% to 1.3% from low- to high-traffic conditions, whereas increased dwell times were seen for the data link (3.4%) and pre-acceptance (12.9%) regions. Fixation frequency, however, seemed much more sensitive to the effects of traffic load. The net change from low to high traffic conditions ranged from -6.3% (for the preacceptance region) to -75.7% (for the timeline). The pattern of scanning can change drastically as illustrated in the next two figures.

Scanning the PVD: low traffic

Figure 21: Sample (120 seconds) of Point of gaze transitions

-46-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Scanning the PVD: high traffic

Figure 22: Sample (120 seconds) of Point of gaze transitions The results indicate that a tool as the scheduler for Arrivals by means of a time line is used especially under the low traffic conditions, but the moment traffic builds up, controllers seem to drop the tool and revert to the classic on screen controlling methods. The paradox that occurs is that tools with technology designed to ease the job of the controller are being discarded especially in the situations where they were anticipated to benefit the most. 5.1.6. The Highly Interactive Problem Solver (HIPS) The exploratory work on the HIPS concept can be identified as a major example of the benefits of working with multi-disciplinary teams. The 4D concept could be visualised by imagining tubes in the sky containing a certain time bubble were the aircraft was planned and contracted to be in during the flight. Two numerically blessed persons, Meckiff and Gibs, came with the wonderful idea to mathematically describe and analyse the interactions between such tubes. These interactions could be plotted on the individual dimensions like lateral, vertical and the time dimension. A next step was to develop displays for such interactions, which would allow the controller to gain insight in the traffic intersections and decide on actions to be taken. This idea was enthusiastically adopted by the GHMI team, but met quite some initial resistance in the ATC community. One reason for that was the use of abstracted displays that allowed a peek in the future. Also the original name for the function developed, was problem solver, and the HIPS was critiqued for not providing automatic solutions. So, it was an example of an automated function that evolved into a tool for the controller, by reworking the display of flight data into meaningful task related information. Principles of the method Originally known as the PHARE Advanced Tools (PATS) Problem Solver, the tool comprises two main components: a set of displays, which give a comprehensive picture of air situations, and an aircraft trajectory editor. These are coupled together to allow route, altitude and speed manoeuvres to be evaluated and implemented in any combination on any aircraft. 'The Problem Solver itself is not an autonomous unit (it does not solve problems by itself, but rather is an interactive tool for use by the airtraffic controller For this reason the concept has been named the Highly Interactive Problem Solver (HIPS). Display of air situations
DOC 99-70-02 Version 1.0 / August 1999 -47-

Results

PHARE GHMI Project, Final Report

The HIPS concept proposes abstracted diagrams as a novel approach for the display of air situations. These are 2D graphical representations of aircraft and performance limits, which present the controller with information in the form of time-independent 'nogo' zones for a chosen subject aircraft. Such 2D displays are an abstracted form of a 4D geometric model of intersections, projections and transformations. There are three forms of abstracted display: route, speed and attitude, corresponding to the three types of basic manoeuvre available to the controller. The most important of these displays, the route display could be superimposed upon conventional synthetic radar or conflict assistance displays. The speed display, on the other hand, provides a quite new perspective, directly showing the effects of manipulating the speed of one aircraft relative to others. This opens up the possibility of using small speed adjustments to solve conflicts - a little used option until now. Trajectory editing

HIPS provides the controller with the possibility to manipulate trajectories in order to avoid the no-go zones displayed on the abstracted diagrams. Solutions may be rapidly achieved due both to the clarity with which the air situation is presented to the controller, allowing possible solutions to be quickly identified, and the simplicity of the mouse operations required to change the trajectory. These displays also provide additional guidance to the controller in the form, for example, of aircraft performance limits to help him achieve a near optimal solution. Trajectories to be edited need not necessarily be those of aircraft in conflict. It is possible for a planner, for example, to rapidly check whether an off-route or direct track is feasible for a particular aircraft traversing his sector. 'This could allow systematic optimisation of trajectories at planning level. The Highly Interactive Problem Solver (HIPS) concept

A simple explanation of the approach, which does not require an understanding of 4D geometry, follows: It is possible to mark on the track of an aircraft's predicted trajectory the sections for which that aircraft will be in conflict with another. If an alternative trajectory (representing, for example, a heading change) is drawn alongside the original, the conflict could be marked in a similar way for that trajectory. If a closely packed series of alternative trajectories are drawn and the conflict zones are marked on each one, then these lines could be combined to form a no-go-zone. These zones are displayed to the controller.

-48-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Figure 23: Construction of a conflict zone Derivation of displays

Consider two aircraft flying at the same attitude at constant speed between two points. It is required to maintain separation between the trajectories of these aircraft: assuming they are allowed to deviate by up to, say, 0.5 nautical miles from their trajectories. The controller wants to ensure that they remain at least 5 nautical miles apart. Computations can rapidly be performed to compare the two trajectories to determine at which points, if any, they come within a margin of 6 (= 5+2*0.5) nautical miles. If one of the trajectories, that of the subject aircraft, is drawn on a display, the section in conflict could be highlighted with a thick line. If the controller wishes to change the heading of the subject aircraft in order to resolve the conflict he may select the point at which the aircraft should turn, and propose a heading change. The new trajectory can be redrawn with the conflict line marked again if it is still present. The controller may try a number of possible headings until he finds one with no conflict - this represents a possible solution to the conflict. Note that during this operation it is possible that for some proposed headings the aircraft would come into conflict with a further aircraft and a conflict line caused by this third (or nth) aircraft would appear somewhere else on the trajectory.

DOC 99-70-02

Version 1.0 / August 1999

-49-

Results

PHARE GHMI Project, Final Report

tr No-go zones

Conflict Trajectory

Figure 24: Abstracted heading display

Figure 25: Speed display principle Finally, the simplest form of speed display shows the trajectory of the subject aircraft plotted with time along the x-axis and distance along the y-axis, so for a trajectory at constant speed the display shows a straight line with a gradient equal to the groundspeed of the air- craft. Once again the parts of the trajectory for which the aircraft is in conflict with environmental aircraft can be marked (Figure 25). A speed change corresponds to a change in the gradient of the line with the start point fixed, and conflict lines can be swept out by moving the line to form conflict zones as before. The controller can choose a speed profile on this display to avoid the conflicts.

-50-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Figure 26: One of the early prototype heading displays in the HIPS. Note the various shapes of no-go zones. The diagrams given above show fairly simple no-go zones for each of the three types of display: in reality the shapes of the zones can become quite complex! Within the GHMI project, they were named blobs in an attempt to do justice to their complex shapes. 5.2. T HE GHMI TRAINING APPROACH 5.2.1. Initial training approach In all PHARE demonstrations/experiments (PD/1, PD/2 & PD/3) air traffic controllers are participating. These air traffic controllers have to learn to work with the system, its HMI and understand the underlying concepts. So training is needed. This section describes the set-up of GHMI training for the three demonstrations. The purpose of the training was twofold. First it was necessary to familiarise the controllers with the overall GHMI and its mechanisms. It was observed in early PD1 trials that controllers would be distracted from their work during the experiments in case they forgot the way to use the mouse functionalities or other GHMI mechanisms. An example is the use of mouse buttons for inputting versus extracting information. In case a mistake was made, confusion could occur. Subsequently, no adequate experience was gained on the advanced tools. As a result the subjective estimates of the usability of such tools could be compromised. Practice on the GHMI basics therefore improves the overall quality of the data obtained in the experiments.

DOC 99-70-02

Version 1.0 / August 1999

-51-

Results

PHARE GHMI Project, Final Report

The second reason was to familiarise the controllers with the fact that the experiment addressed an experimental system and not a pre-operational system. In case of the latter system, it is important to note all details relevant for day-to day work. Examples are ergonomics of seats, screen layout optimised for local situation etc. In the PHARE experiments it are the concepts and ideas that are under test. After positive results, still much work has to be performed in order to create a true pre-operational system. PD/1 and PD/2 the HMI (Human Machine Interface), and understanding of the concepts on which the system is based and use of the different tools in the system for new air traffic control. The first part of the training took place on workstations, in which the HMI of the real system was adapted. Step by step, the different tools in the system became active and could be learned and practised, guided by a paper explanation (1st demonstration) or by explanations and instructions displayed in a window on the screen (2nd demonstration). The lessons consisted of an explanation part and a practice part. Feedback was given by instructors/coaches (1st demonstration) or by simple tests and feedback for the most complex lessons (2nd demonstration). The second part of the training was given on a high-end ATC simulator, in which the focus was on team training. The system resembled the real system, but did not contain features such as communication with (pseudo) pilots and the use of headsets. The use of the real system in different situations from simple to complex was practised. The last part of the training was given on the real system (the actual demonstration system), focusing on applying the learned knowledge and skills in practice. Further, practice features as headsets and communication with (pseudo-) pilots were added. Lessons learnt HMI familiarisation is needed for improving the overall quality of the demonstrations by helping the controller to work the system. Massed practice does not work as effective as distributed practice in the first part of the training. Sending preparatory (paper) material to controllers in advance helps in understanding the system and speeds up the learning process. The initial acquisition of knowledge and skills by a computer integrated training as used in PD2 is worthwhile and gives positive transfer to the simulator and the real system. Computer based training should be developed and explored more. Use of paper reference guides and an AID MEMOIR, that summarise the system characteristics (on-screen), working procedures and tools is very useful in the second part of the training on the simulator. Central to the training are clusters of skills associated with:

The training for PD/1 and PD/2 was set up as follows:

Lessons learnt from the training in the first two demonstrations are:

-52-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Free navigation through the CBT and practice of interactions as often as wanted is necessary in learning such a complex system. Explanations, interactions and reactions of the system should be integrated and focused around the interaction of the controller. A performance monitoring system with a good test and feedback structure is needed in the beginning of the training. Self-discovery/ freeplay moments are very useful in the later stages of learning, in which the system can be experienced in specific ATC situations.

5.2.2. The CBT HMI familiarisation approach Training for the third demonstration

The third demonstration was quite more complex, because it combines the first two demonstrations with additional improvements. The training for this last demonstration took into account the lessons learnt from the training for the first two demonstrations. In this case a dedicated computer based training package was build for use on a personal computer. This package was designed to support overall training and its functionalitys with respect to active simulation capabilities were naturally limited. The use of a stand alone ATC system for completion of the local training proved feasible and beneficial, as it includes exactly all the local GHMI details concerning sectors etc. Note that a systematic and structured approach towards training is always essential and such an approach needs to be based on a training needs analysis and a skill based training system specification. In the PHARE programme, a combination of training systems was explored.

DOC 99-70-02

Version 1.0 / August 1999

-53-

Results

PHARE GHMI Project, Final Report

PD/3 training organisation

The training for the third demonstration was set up as displayed below.
Computer Based Training on PC
HMI familiarisation & Concepts Integrated explanations & interactions Tests & feedback Practice and rehearsal as often as needed Distance learning (anywhere, anytime)

After rehearsal of (set of) CBT lesson(s) on simulator


Training on ATC simulator
HMI rehearsal Working procedures (how to use the system for ATC situations) Team training (co-ordination) Real system with traffic scenarios (simple complex) ATCO Handbook Instructors/coaches

Training on the real system

Rehearsal of using ATC system Context features (e.g. (pseudo)-pilots, headsets)

The first part of the training computer based training (CBT) on a PC is used in which familiarisation with the HMI and system concepts are learned. CBT has also the characteristics needed to improve the first stage of learning: performance monitoring, integration of knowledge and skills, individual pace of learning and independent of location. Further, the CBT can be used in a distance learning event (at home or at the ATC centre, instead of at the demonstration site), as preparatory learning material. Each (set of) CBT lesson(s) was rehearsed on the ATC simulator immediately after having completed the CBT lesson(s) for HMI rehearsal. After having completed all CBT lessons, the second part of training took place on a high-end ATC simulator. This training system resembles the real system, but has no features such as (pseudo) pilots and headsets. A handbook is used to structure the training on the simulator. The handbook consists of paper reference guides for interaction with the tools and working procedures. A coach monitors the performance and gives guidance, help and feedback where needed. The training starts with progressive part task training and ends with sessions in a whole task training.

-54-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

PD/3 training instructional principles

In the computer based training on the PC, step by step system tools will be explained and interactions can be practised as often as wanted (part practice). In the figure below, a screen dump of the CBT is displayed. Explanations and interactions are integrated: the knowledge is available while practising a skill). Each lesson consists of: An explanation of the tool (purpose, parts, functioning). Practice of the interactions with the tool. Pop-up help that can be activated during the practice of interactions. The help explains the different parts of the tool. Tests and Feedback, consisting of items such as denoting the parts of a tool, performing an interaction, selecting right/wrong statements. After each test item feedback is given and advice is given on which parts to rehearse.

After the computer based training, the controllers understand the underlying concepts and are able to interact with the system.

Computer Based Training


During the subsequent training on the ATC simulator, the use of the system in different situations from simple to complex will be practised and experienced. The ATC simulator has pausing and replay possibilities of scenarios. Learned knowledge can be accessed through the paper reference guides in the handbook. The coach, either during practice or in little debriefing sessions gives feedback after completing a training part. To summarise, the training on the ATC simulator consisted of three parts:

DOC 99-70-02

Version 1.0 / August 1999

-55-

Results

PHARE GHMI Project, Final Report

Rehearsal of interactions because they are not yet experienced in the functionality of the real system (intertwined with CBT lessons on GHMI and concept). Working procedures (how to control air traffic using the new system and its tools) are learned for specific controller working positions. Situations varied from simple to complex. Team training, in which the working procedures are practised in a team and specific co-ordination procedures are learned.

5.2.3. Training benefits The integrated Training approach combining part task and full mission training on the stand-alone systems was generally regarded as very essential for the success of the programme. The HMIs are quite complex with a wide range of facilities to be used by users that can be quite unfamiliar with some of the basic tools like three button mice, direct object manipulation etc. Computer illiteracy is expected to disappear in the near future, but nevertheless, dedicated training is needed for working with new experimental systems. A positive side effect of the CBT part task training was that it could be distributed to all kinds of interested parties, before the actual experiments. The software was distributed on CD and could be used on home PCs. This strategy proved highly effective in improving the overall participation in and acceptance of advanced concepts. Distant learning concepts should always be combined with a test option (on- or off line) in order to be able to verify the level of knowledge on theory achieved theory by the participant. In that way all participants start the sessions with a common base level of understanding. A negative aspect of the CBT is that the available authoring tools are essentially limited in their capability to include live simulations. When used for distant learning, ideally some coaching function should be included. Further development of authoring tools is clearly needed to create more options for the training designers to reach their training goals without being forced to work around computing limitations. A first exposure, assisted by a coach is to be preferred at this stage of technology. The use of observers/ instructors in the trials with both a design and human factors expertise, proved useful as their background allows them to effectively detect that some procedure or tool was apparently not adequately understood during practice and therefore, artificially, not being used by the controller. Remedies could be provided quickly and individually, allowing the controller more freedom of selecting control options available. A continuation of the training approach is highly recommended. Future research should extend the scope of the training tools available and integrate its facilities into a full comprehensive set that would support experiments and could be re-used /modified to facilitate the transitions to the new equipment configuration.

-56-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

5.3.

T HE GHMI DESIGNS 5.3.1. The en-route GHMI (PD-1) The PD/1 System Operational Concept

The PD/1 operational concept was built around the basic assumption that the human would retain the ultimate authority for ensuring the safety of all flights. The current controller roles of planner and tactical were therefore retained. No paper or electronic flight strips were used; instead, the information was presented to controllers through interactive track data blocks and sector inbound lists displayed on the controller's main radar screen. The PD/1 baseline concept contained some simple computer assistance tools. The operational concept was based upon aircraft having modern flight management systems that would allow them to navigate with high precision on any desired track. Some of the aircraft would be able to fly 4-D trajectories; that is, fly a three dimensional path in space whilst arriving at specified locations at specified times. When an aircraft first enters the airspace the pilot would datalink details of the requested trajectory to the planning controller on the ground; typically, such a trajectory would cover the next 20 to 30 minutes of flight. Using the computer assistance tools the planning controller would check for conflicts with other aircraft and, if any were found, suggest a different trajectory to resolve the conflict. The alternative trajectory would be sent back to the aircraft to check that it could indeed fly the requested path. Once the trajectory is agreed by both pilot and controller, it would be input to the aircraft's flight management system which then flies the aircraft along the trajectory whilst being closely monitored by the pilot. The ground surveillance system would monitor the aircraft's actual flight path and warn the tactical controller if any significant deviations were detected. The controller would then intervene tactically to prevent any conflicts occurring. In the early years of such an ATC system there would be many older aircraft still flying. In particular, not all aircraft could be expected to have a 4-D trajectory capability. Instead, they would be restricted to fly three-dimensional paths without time constraints. These aircraft would also not have the avionics systems necessary to allow the dialogue between the ground and the airborne system. In such cases the ground system would calculate a 'good' trajectory for the aircraft based on its type, its origin and destination, its altitude and other factors. Again, the proposed trajectory would be checked by the planning controller to ensure it was conflict free, and modified if necessary. For those 3- D aircraft without datalink facilities, individual clearances would be passed, at the appropriate time, to the pilot by the tactical controller over the voice R/T channel.

DOC 99-70-02

Version 1.0 / August 1999

-57-

Results

PHARE GHMI Project, Final Report

PHARE Advanced Tools

An ATC system such as that implemented in PD/1 depends critically on the controller having appropriate computer assistance tools. To implement the system as described above, the ground system must be able to predict where the aircraft will be in the future. The controller must be able to tell whether the predicted trajectory will be in conflict with any other aircraft's predicted trajectory; and the controller must be warned when an aircraft is not following its agreed trajectory. To perform these tasks a number of computer algorithms or tools were developed. The PHARE advanced tools (PATS) used in PD/1 were the: trajectory predictor; conflict probe; flight path monitor; problem solver.

The trajectory predictor (TP) is a ground-based version of the tool used in the airborne Experimental FMS (EFMS) to predict the trajectory of the aircraft. The ground TP uses a database of aircraft performance characteristics, the initial flight plans and trajectory constraints entered from the GHMI to generate close-to-optimal 4-D trajectories for each flight. It allows the controller to carry out accurate 'what-if' modelling with tools such as the Problem Solver (see below). Although the TP is capable of forecasting an entire flight from take-off to landing, in PD/1 the forecasts were limited to the 20-30 minutes flying time for flight across the simulated airspace. The conflict probe (CP) operates automatically on each trajectory in the flight database comparing it with every other trajectory to identify any loss of separation. If a conflict is found, the CP reports the 2 aircraft involved, including details such as start of conflict and closest point of approach. This information is thus available to other tools and to the GHMI for display to the controller. The conflict probe will also pass information to the tools and GHMI when a conflict is cleared allowing the system displays to be updated. The flight path monitor (FPM) cheeks over 'radar' reported aircraft position against the stored 4-D trajectory for the aircraft. If the aircraft has deviated significantly in any dimension from the modelled 4-D trajectory the FPM raises a deviation alert for the GHMI to display to the controller. The deviation alert gives full information on the deviation in all dimensions. However, in the PD/1 system not all information is displayed to the controller by the GHMI. The FPM also has the task of reporting when an aircraft has passed a significant point on its trajectory. Such a point is identified to the FPM by one of the system tools and the FPM alerts the tools when the subject aircraft passes that point. The Problem solver, unlike the other PATS, that are not immediately visible to the controller, the Highly Interactive Problem Solver (HIPS) was one of the main GHMI interfaces for the controller with system. HIPS is a sophisticated computer assistance tool which allows the controller to view several dimensions of the aircraft's proposed trajectory to check that it is conflict free and to edit, negotiate and agree trajectories using a horizontal, altitude or speed/ time view of the aircraft's predicted trajectory.

-58-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

In addition to the HIPS, other components of the GHMI used by the controllers drew information from the tools. They included: The augmented dynamic flight leg (ADFL) - which allowed controllers to highlight an aircraft's trajectory in the plan view display ('radar screen') and to accept it or propose changes; The conflict risk display (CRD) - which showed all potential losses of separation between aircraft in terms of how soon they could occur and what the minimum separation would be; The conflict zoom window (CZW) - which showed a forecast of the aircraft tracks for a particular conflict at the time of closest approach; The horizontal and vertical assistance windows (HAW and VAW)- which showed aircraft positions The communications list window (CLW): this prompted the tactical controller to issue instructions in a timely manner to non data linked aircraft. GHMI Design Aspects A major issue in designing new systems from scratch, is the lack of clarity about the exact working procedures to be handled in such a system and the corresponding controller strategies. As the exercise was experimental in nature, a decision was made not to restrict the HMI to a particular working method, but to study the spontaneous use of tools and equipment. The GHMI in the end could support multiple roles (tactical/ planner) and could be reconfigured on many details including preferences of the controller. The HMI comprised a basic set of PHARE advanced tools in a window managed environment, that could be configured to a particular scenario and to the Planning or Tactical controller. The principle of 'Direct Object Manipulation' was applied to all screen objects including aircraft trajectory manipulation. Interactive Track Data Blocks (TDB) provided information that made flight strips redundant. The display formats design was guided by human factor principles and a task oriented logic. Colour application was task relevant and acceptable from a human visual perception standpoint. The human machine interface provided consistent feedback on controller actions and System State in order to increase system awareness. The applied 'minimal information' principle prevented display cluttering by removing information that is task irrelevant for the moment, leaving the basic configuration at all times. All data were accessible by multiple means, and with minimal input actions required, and did not impose a particular working method or strategy. The use of a re configurable configuration allowed a stepwise experimental design for the evaluation of the effectiveness of a particular tool or HMI component, without confounding with other lay-outs. All configurations are tested against a 'baseline' or 'reference system' that is as close to existing systems as possible. This allowed quantification of the respective benefits for traffic throughput, controller performance and workload. The hardware on which the controller working positions were implemented included large size colour displays with 2k x2k pixels. The input device was a three-button mouse

DOC 99-70-02

Version 1.0 / August 1999

-59-

Results

PHARE GHMI Project, Final Report

The reference system had the following characteristics: paper less, window based design; simple tools based on 10 minutes look a head; conflict risk window, conflict zoom window, horizontal (HAW)and vertical assistance windows (VAW); current controller roles of Planner and Tactical were maintained; radio communications with aircraft and both telephone and data link communication between sectors.

The advanced configurations added both better qualities of data and new tools: down linked data was available from aircraft trajectory prediction and on screen review on screen trajectory manipulation through 'Augmented Dynamic Flight Leg' (ADFL) capability to create proposals to aircraft trajectory support tool (TST) and status indicators to assist negotiations with aircraft special window with problem solving tool, the so-called 'HIPS' data link communications between aircraft and ground deviation alerts through a Flight Path Monitor tool (FPM)

-60-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Illustrations
Plan view display HIPS speed view Selected aircraft

ADFL

Track Data Block

HIPS altitude view

HIPS horizontal view

Figure 27: he GHMI PD1 PVD design and tools like the HIPS, sector inbound lists etc. Results

The experience with the controller working position and HMI for the en-route, was exciting and well received. No controllers felt deprived of flight strips either paper or electronic, interactive data blocks were sufficient. The colour-coding concept for indication of aircraft status was significantly accepted by the controllers, and rated as being comprehensible and useful. The combination of a mouse with a windowing environment was significantly accepted. Training is required by some to obtain mouse experience, while others require practice for getting used to a three-button design. The familiarisation and training package proved essential for introducing new concepts. Still unfamiliarity with the interface occurred and caused problems. Adequate computer power is essential to realise fast HMI and tool response times. Controllers developed a tendency to want to look ahead in the next sectors, indicating that with modern technologies sectors should be increased as compared with today.
DOC 99-70-02 Version 1.0 / August 1999 -61-

Results

PHARE GHMI Project, Final Report

Controllers tend to revert to their old controlling methods under highly loading conditions. Training scenarios should emphasise the use of tools under these conditions to prevent 'high traffic panic' Age, computer literacy, learning ability and type of procedures being used to, were factors in adapting to new concepts and procedures. Transitions are clearly ameliorated by the training package. Some detailed features were not actually used spontaneously, and should either be discarded or re-evaluated on their utility. More prototyping could have resolved this issue. The vertical and horizontal assistance windows in the 'old' technology based reference system proved of little value. The conflict risk display was relied on especially during busy traffic to allow earlier re planning options. HAW and VAW, CRD were not highly used while HIPS, ADFL and TDB and CLW were almost popular and very well received. Appreciation of the ADFL was uniformly positive. Controllers, who achieved high proficiency, seemed to favour the HIPS over the Dynamic flight leg, while less proficient controllers favoured the Dynamic flight leg, a more traditional approach to planning. The HIPS proved to be a powerful tool, that makes conflicts a pleasure to resolve, but represent a tool separated from the traffic window, which could reduce overall traffic awareness when used extensively. The speed profile was relatively unfamiliar to the controllers and difficult to interpret. The CLW was received well, but some tactical controllers objected to the CLW dictating them when to issue the R/T. The role of the planner controller became more dominant, with little left for the tactical. The percentage of participating controllers that frequently used the respective facilities is depicted in Figure 28.

100 80 60 40 20 ADFL CZW CLW HAW HIPS VAW CRD 0 % used

Figure 28: Percentage of controllers who reported frequent use of a particular facility. Note that ADFL, CLW are HIPS are part of the future system. Discussion

-62-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

The PD1 trial could only be realised by excellent teamwork between many parties. The concept was highly advanced and represented a significant step away from the state of the art controller working positions. So, it was open for criticism and suggestions as it concerned an experimental system, not a pre-operational system. Nevertheless, after working the system, controllers quickly adapted to and adopted many of the features in the design. The use of a coloured windowing environment, as an example, met many comments, as the colours were generally perceived as a bit pale. The reason for that was that controllers have to work for extended periods, and high contrasts etc. will induce visual fatigue. On first sight, the colours were not appreciated, but after working with them, acceptance was raised, demonstrating the importance of actually working with such experimental systems. A major result of the exercise was that the planner could handle almost all work. The tactical controller, having little to do, started intervening with traffic and therefore with the plans made. Normally, the tactical serves a team leader and the planner assists. The results therefore clearly hinted that a role change could be in order when using such advanced controller working positions. 5.3.2. The approach GHMI (PD-2) The PD/2 System Operational Concept

PD/2 focused on the future management of arrival traffic in an Extended TMA. No major changes in roles for the controllers were anticipated for a near term implementation. Controller working procedures, the working environment and the airspace structure were therefore quite similar to the current system. The advanced mode comprises a strip-less environment with 4-D profile planning and conflict detection & resolution of planning conflicts. An arrival planning system (Arrival Manager) resolves planning conflicts by separating all arriving aircraft in space and time. Advisories displayed to the controller are generated by the ground system in order to support them in meeting the constraints of the Arrival Manager. Deviations of aircraft from the planned trajectory as well as unsolved conflicts between planned trajectories have to be resolved manually. The system supports the controller in this process by measuring deviations and displaying them in time and space against the planned trajectory. The 4-D FMS equipped aircraft use datalink to negotiate and implement airborne calculated trajectories that meet the constraints developed by the AM with respect to arrival sequence and schedule. For unequipped aircraft RT will give the trajectory support. Three guidance modes can be applied: Class A aircraft concerns 4-D FMS and datalink equipped aircraft with automatic implementation of the trajectory. Class B aircraft concerns all aircraft that are guided via R/T, and for which the ground system has support in the form of a conflict-free trajectory and the associated advisories. Class M aircraft are guided manually via R/T without a valid trajectory, as applied in the current systems.

DOC 99-70-02

Version 1.0 / August 1999

-63-

Results

PHARE GHMI Project, Final Report

Controllers monitor the flight progress of a Class A aircraft that will fly without R/T communications other than initial call and frequency change when leaving the sector. In case of a problem, the controller can assume command via the R/T which implies that the negotiated contract is no longer valid. The status of the aircraft automatically changes from Class A to manual mode as the system is updated about such tactical intervention by GHMI input. It was not possible to regain a Class A status after such intervention due to limitations in the PD2 equipment. The Tactical Controller transmits the 4D-Guidance advisories produced by the ground system via R/T to the aircraft (Class B guidance). The performance of the advanced system was compared with a reference system with more standard type of facilities such as (radar data, flight plan data, paper flight strips, weather information, radio communication) and assistance from a simpler arrival planning system providing basic sequencing and scheduling. PHARE Advanced Tools Trajectory Predictor (TP)- the TP generates the trajectory information for each aircraft. In PD/2 only the arrival part of the trajectory was used, equivalent to about 30 minutes flying time including the top of descent from cruise level until the Approach Gate (10 NM from runway threshold). All trajectories were generated using standard arrival routes (STARs). Conflict Probe (CP)- the Conflict Probe compares the new trajectory of an aircraft entering the simulation with all trajectories already stored within the flight database of the ground system. Any violation of separation criteria like radar separation or wake vortex separation is identified and displayed in space and time. Flight Path Monitor (FPM)- the Flight Path Monitor compares each radar position of an aircraft against the 4-D position taken from the active trajectory stored in the ground system. Deviations in terms of distance in space and time are produced with the surveillance update rate, for further processing by the supporting tools like the Arrival Manager, and for display to the controllers. Negotiation Manager (NM) -the Negotiation Manager takes care of the air-ground exchange of information with respect to trajectories. It provides an interface between the ground-based tool set and the 4-D FMS equipped aircraft equipped with an airground datalink. Arrival Manager (AM)-the Arrival Manager is the core tool in the PD/2 environment. It overviews multiple sectors in order to provide optimised scheduling and sequencing advisories for all arriving aircraft. Basic AM functionality is in use in today systems; based on arrival time prediction, for instance COMPAS. That basic functionality is extended with trajectory information, generated by either airborne or ground based trajectory predictor systems. The Arrival manager has four main components: the Arrival Time Predictor, Sequencer, 4-D Descent Manager and the Approach Problem Solver.

-64-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Arrival Time Predictor The arrival time predictor gathers all necessary information like airspace data and flight plan data, to prepare a constraint list. This constraint list is sent to the TP tool for ground-based calculation of a preferred trajectory together with the earliest and latest possible arrival time at the Approach Gate. If alternative routes are possible, like the West Approaches in PD/2, a trajectory with the set of estimated arrival times for the alternative routes is stored. Each entry of a new inbound flight activates the Arrival Time Predictor Module. Sequencer The sequencer tool provides the sequencing and scheduling functionality of the Arrival Manager. In the first step the preferred times at the Approach Gate are checked against separation violations in time. If the CP reports no conflict the aircraft is scheduled for the preferred time. If the aircraft is 4-D FMS equipped, the NM tool is activated to initiate a negotiation via datalink. The ground constraints list is uplinked and the aircraft downlinks an airborne trajectory. This trajectory is checked again by the CP against all other trajectories already planned and agreed. If no problems are detected the airborne trajectory replaces the one calculated by the TP. If aircraft are in conflict with their arrival times a branch and bound algorithm is activated to sequence according to predetermined rules like first come first serve, close gaps in the sequence, optimise wake vortex categories. The arrival times are varied within the earliest and latest time limits in order to optimise the sequence. If alternative routes are allowed, which even may belong to different runways, these routes will be checked for a better solution. This leads to a set of new constraints and the generation of a new trajectory by the TP fulfilling the new constraint for arrival times and possibly for a new runway allocation. If the CP tool finds no conflicts the aircraft are scheduled for that target time. At the border of the Extended TMA an equipped aircraft will go through the following sequence of air-ground negotiation steps in order to get a contract to implement the trajectory automatically: Uplink of Constraints A message is uplinked containing the route identifier and time constraints at the gate. This requires that the AM Manager has completed the 4-D planning of this aircraft, on the basis of information available on the ground. This can be a ground based TP trajectory, or a trajectory downlinked earlier by the aircraft in a previous sector. Downlink of Trajectory The aircraft processes the constraints and downlinks a trajectory. If the aircraft cannot meet the constraints it says so. This aircraft will then be guided via Radio Telephony (R/T) as an unequipped aircraft. Approach Problem Solver- in case of conflicts found by the CP the AM varies altitude and time constraints in order to obtain a conflict free trajectory. This capability was limited to arrivals trajectories. If no solution is found the scheduled time in the arrival sequence is maintained but the trajectory is displayed as being in conflict to the controllers. It is now the task of the controllers to vector the aircraft from its route to avoid the predicted conflict area.

DOC 99-70-02

Version 1.0 / August 1999

-65-

Results

PHARE GHMI Project, Final Report

4-D Descent Manager - the task of the 4-D Descent Manager module is to implement each scheduled trajectory. The trajectory is translated into advisories that can serve as control commands for R/T. Advisories are generated for turns, descents, descent rates, and speeds. In addition the position and time of application is produced. These data are transferred to the GHMI before expected execution time in order to allow an advanced indication to the controllers. Deviation messages given regularly by the Flight Path Monitor are used by the 4-D Descent Manager to decide whether the guidance mode of an aircraft has to be changed. GHMI Design Aspects The GHMI used in PD/2 provided a prototype of a paperless system for approach control. It consists of a multi-window environment that can be configured to fit the respective controller roles, preferences etc. The main elements available on each working position were the Plan View Display for the Radar information together with a Conflict Risk Display (CRD) and an Arrival Management Display for the planning controllers on a separate screen. Only for the ACC controllers additional Sector Inbound List windows were shown on the PVD in order to provide flight plan information in advance for selectable entry and exit fixes. In the ACC-position an additional Vertical View Display (VVD) window provided a vertical view of the traffic over fixes where holding patterns are normally located. However, note that holding patterns were planned not to be used in the PD/2 simulations. The plan view display T he PVD depicts the airspace together with the labelled radar targets. A radar toolbox window allows the controller to select the centre, scale, number of history dots displayed with the radar targets as well as the airspace elements. Also a label positioning method can be selected. The controllers can (de-) select the Conflict Risk Display (CRD) that pops up every time a conflict is detected. This window indicates each conflict as a small red box, indicating the time ahead of a conflict (in minutes) and the minimum distance at conflict time (in nautical miles). The call signs of the conflicting aircraft are listed. By clicking on the red box the controller can highlight the labels of the associated aircraft at both the PVD and AMD. No short-term conflict alert was included in the PD/2 system. Aircraft Label The main interaction mechanism is label oriented. A controller selects a label by moving the mouse cursor over the label. Selection is indicated automatically by a background field containing the label lines in inverse colour. The label colours grey, pink and white indicate whether the aircraft is either controlled by other controllers, is in a transfer status, or is under own control. Transfer could be initiated by clicking the transfer field in the upper left corner of each label. An alternative method is to input flight level, airspeed, and rate of descent/climb values on pop-up menus at the labels. By clicking on the 'heading' field an arrow can be turned around the radar target by the mouse, thus helping to select a heading value, which is also indicated numerically. Inputs are given with the left mouse button. By pressing the right mouse button over a label the label information is extended with additional data like destination airport, weight class etc. Label interaction was also available on the AMD and VVD by moving the mouse over the callsign indicator of an aircraft.

-66-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

The target shape shows the equipment of an aircraft. A square indicates 4-D equipment (datalink and 4-D FMS), a circle indicates non-4-D equipped aircraft. A 4-D aircraft with a cleared contract (Class A aircraft) is shown as a filled square. Class B aircraft (with ground trajectory support only) are indicated as an open circle or square. If an aircraft is guided manually the target becomes yellow. The advisories of the Arrival Manager are displayed in orange in a third label line for advised altitude/flight level, airspeed, heading, rate of descent, and are preceded by a tick marker field that can be clicked on by the controller if the R/T command is activated. In that case the third line shows the last cleared FL if the aircraft has not reached it. The orange advisories disappear automatically when the time of application is reached. Trajectory representation
Figure 29 shows the PVD representation with selected label and complete trajectory on the example of SAS171 arriving on a northern route via the metering fix Gedern to RWY 25R on the left bottom of the figure.
selected label SAS 171 B737 : last cleared FL current FL speed heading : FL 125 : FL 210 : 360 kts : 182 deceleration 300 kts -> 250 kts
SAS171 210 36 B737 EDDF 182 -1820

descent FL 100 -> FL 80 Metering Fix GEDERN (GED)

descent FL 80 -> FL 70 descent FL 70 -> 3000 ft

deceleration 250 kts -> 220 kts

Figure 29: Trajectory Presentation at the PVD

DOC 99-70-02

Version 1.0 / August 1999

-67-

Results

PHARE GHMI Project, Final Report

The trajectory information on the PVD is graphically represented as a blue line along the whole route for each aircraft. The planned position of an aircraft is marked as a blue cross at the trajectory line. Another option is to visualise the future planned paths as blue lines starting with a cross at the planned present position. The length of this future-line is selectable (in steps of 1 minute). Special markers on that trajectory indicate significant positions where the aircraft status will undergo changes. Examples are start/end of descent or speed changes together with the previous and new target values written at the markers in two lines. In addition, for class B aircraft yellow markers show where to apply the necessary advisories. An open square is used for a heading, a tilt cross for altitude and a cross for speed advisory positions. These markers disappear when the advisory is marked as completed by the controller. Arrival Management Display (AMD) Sequence and scheduled time as calculated by the AM is represented on a time scale (time ladder), progressing from top to bottom. The next figure shows the AM display layout for the Approach Controllers. Here the time for the Approach Gate is the reference time. For ACC West the time over metering fix RUD is the reference time.

heavy

3-D / class B

planning time SAB513: 10:28:20

4-D / class A

label colour green: arrival via RUD

label colour yellow: label colour yellow: arrival via PSA PSA arrival via

delay pointer delay pointer label colourblue: blue: label colour arrival via GED arrival via GED

actual at GATE: GATE: 10:15 actual time at

actual time: 10:15 10:15 actual time:

aircraft planned for runway 25L

aircraft planned for runway 25R

-68-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

The input buttons shown at the right allow interactions with the Arrival Manager about significant changes of constraints, like e.g. RWY direction change, or new slots, changes of minimum separation etc. This functionality was however not used in PD/2 in order to keep the traffic demand during the experiments unchanged. The aircraft labels in the AM Display of the Approach indicate the runway allocation, 25Left or 25Right. They are framed in different colours showing the different arrival routes (blue = north, yellow = south, green = west). Aside of each label frame the angle of the 'delay pointer' shows the deviation in time as measured by the FPM. An upward (downward) pointer indicates whether aircraft are delayed, whereas a horizontal tail line indicates no delay Trials Facility The PD/2 trials were conducted on the Air Traffic Management and Operations Simulator ATMOS of DLR. This section provides a brief overview of the facility and its configuration for the trials. The picture below gives an impression of the ATMOS environment and the controller working positions.

Planner ACC

Observer Pickup Feeder

Figure 30: Working positions of ATMOS during the PD/2 Experiment.

DOC 99-70-02

Version 1.0 / August 1999

-69-

Results

PHARE GHMI Project, Final Report

Results

The use of the mouse was again significantly accepted as a suitable device for interacting with radar labels and pop-up menus, but sometimes an overloaded simulation system caused slow response times making it difficult to select specific elements. Controllers generally agreed with the screen layout and size, as well with the readability of text, and there were no problems with the abbreviations used. Also the concept of colour coding of the labels, for indication of the control status, was regarded as being highly comprehensible and useful. Together with the indication of the actual mode of guidance (class A, class B, or manually guided) which was given by the aircraft symbol, these were significantly well accepted by the controllers. The options of changing the displayed length of the trajectory prediction and changing the track history which enabled controllers to have a look on the past and the future of any aircrafts flight path, were highly appreciated. Analysis of controller roles revealed a re-distribution of workload between tactical controller positions. A decrease of workload was found for the Approach Pickup controller position, which normally represents the position with the relatively highest workload. The effect of relieving the controllers from transferring ATC instructions was marked. So the addition of more equipped aircraft would increasingly benefit the overall workload levels. One particular lesson learnt was that advanced designs clearly challenge the capability of many simulation platforms. In PD2, some functionality had to be adapted/ limited in order to be able to run the simulations and not overload the system. Controllers were not as free in their strategies as in PD1. If so, they could have messed up the traffic scenarios. The results of the study are therefore obtained in a more ideal world, as would normally be the case. The application of the tools was therefore more oriented towards automatic operations and traffic patterns changed as a result. The traffic patterns are illustrated below.

-70-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

The percentage of participating controllers that frequently used the respective facilities is depicted in the next figure. Note that the use of the VVD is artificially restricted by the PD2 scenario, as no holding patterns were to be present due to advanced planning. Alternative scenarios would likely result in more extended use.
70 60 50 40 30 20 10 0 CRD VVD AMD SIL % of use

Figure 31: Radar plots by traditional ATC of one controller team in a high traffic scenario.

DOC 99-70-02

Version 1.0 / August 1999

-71-

Results

PHARE GHMI Project, Final Report

Figure 32: Radar plots by advanced PD2 ATC of one controller team in a high traffic scenario.

Discussion

The PD2 trial illustrated that a more automatic world could provide quite consistent and efficient traffic patterns. However, no real life disturbances were simulated due to restrictions in the simulation environment. However, it led to a revival of discussion on what kind of strategy would be best for the future. Computing power is really required for GHMIs to be effective in their response and match the quick thinking of its users. In order to save valuable time an alternative idea was put forward with respect to tools arrangements. Suppose that an aircraft wants a change in route. It downlinks the trajectory to the ground and the controller is notified. Now the controller has to decide and switch on the conflict probe to see if the request would pose a problem. An alternative would be to directly load the request into the conflict probe. No problem detected? Than an approval is immediately sent to the aircraft. Whatever appeal such a strategy may have from a technical point of view, it implies that the controller is kept out of the loop. No behavioural data on the consequences of such a working method for the level of traffic awareness of the controller is available yet. Clearly, more research on the issue is required when pursuing such a configuration.

-72-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

5.3.3. The multi-sector Gate to Gate GHMIs (PD-3) Organisations Overview

PD/3 is a real-time simulation comprising two organisations; a Baseline and an Advanced Organisation. The baseline organisation is a reference close to the today's operational situation. The Advanced Organisation is characterised by the following concepts: - Human centred approach for automation; - Multi-sector environment; - Traffic organisation and 4D-trajectory negotiation. The advanced operational scenario proposes concepts to EATMS, for the time period from 2005 to 2015, when the traffic mix will progressively comprise a population of 4D equipped aircraft, increasing to a significant ratio: around 70% equipped aircraft. Rationale of The Concept The aim of the PD/3 programme is to design a scenario for an air traffic environment within the core area of Europe, with potential for a significant capacity increase over that of the present air traffic system while benefiting airline operators with more economical flights. Extra capacity will be found with the introduction of new flight management and precision navigation systems, data-link communication, multi-layer planning techniques, and advanced ATC tools to improve air traffic management. The integration of these developments into a single air- ground entity, while retaining the decisive roles of Air Traffic Controllers and Pilots is a prime objective of the PD/3 Advanced Organisation. Air traffic congestion does not occur evenly throughout a system, but appears as isolated complexity zones, in different sectors at different times. These areas of complex traffic put extra demand on the Air Traffic Controllers and their systems, resulting in impeded traffic flows, flight restrictions and ultimately reduced capacity. Introduction of advanced flight management systems (EFMS) will allow the accurate projection of flight trajectories and permit forward, multi-layered planning. Communication congestion will be addressed by the introduction of two-way data-link communication permitting the silent exchange of large amounts of information necessary within the proposed environment. The restructuring of ATC planning and the addition of an extra multi-sector Planning layer could improve present Air Traffic Management. Air Traffic Flow Management provides a strategic planning service several hours before the aircraft enters the air traffic control sector, where the tactical controllers are operating only a few minutes ahead of the aircraft conflicts. The role of a Multi Sector Planner will be to offer medium-level strategy rather than tactical solutions to overcome traffic complexity. Aircraft trajectories will be planned over several sectors. The aim is to reduce the workload of sector controllers and provide more optimal trajectories for suitably equipped aircraft.

DOC 99-70-02

Version 1.0 / August 1999

-73-

Results

PHARE GHMI Project, Final Report

The roles of the sector controllers will be changed to allow anticipated planning by the sector planning controller while assisting the sector tactical controller and providing each controller with complementary tasks consistent with the planning time horizon. The three layers of planning and control shall provide for adequate control of the traffic situation at all intervention levels. Air Traffic Controllers will be assisted by the provision of a set of advanced tools (PATS) designed to aid the decision making process, permit the timely exchange of data and to improve the aircraft role in the flight planning process. An important feature of the Advanced Organisation selected for evaluating the PD/3 concept is that the Air Traffic Controller and Pilot retain central roles. The Human Centred Approach (HCA) is emphasised and the appropriate balance between the system processes and human interest is retained. The Advanced Organisation described in the following pages is based on a rationalisation of previous concepts featuring the Human Centred Approach and a level of more strategy traffic organisation. The organisation selected involves the MSP in partial de-conflicting while considering strategic objectives. Several considerations and limitations were necessary when selecting the Advanced Organisation. It was recognised that the proposed environment required the investment of airline operating companies in costly new equipment. The Advanced Organisation must therefore provide a measurable cost benefit for equipped aircraft to fund this investment, without increasing the system handling demands for non equipped aircraft. Limitations included a shortage of time for educating controllers in working methods very different from those currently in use and experimental constraints limiting the number of different organisations that could be evaluated. The selected Advanced Organisation presents a scenario where the main concept can be evaluated, however various options have been identified to enhance the experimental process and provide extra clarification. These include variations in the mix of data-link equipped aircraft, changes in the controllers roles, different airspace configurations and testing of the impact of Arrival Management on planning procedures. Further options were considered that might warrant future investigation. Although fundamental airspace, route and sectorisation changes are anticipated following implementation of a new planning structure the specific changes are not yet defined. Upper flight level allocation may also change with the introduction of Reduced Vertical Separation Minima (RVSM), however RVSM implementation is still being considered. The Advanced Organisation therefore utilises existing airspace, route structures and flight level allocations with current aircraft performance also retained. The selected Advanced Organisation provides for a validation of the PD/3 concept, incorporating knowledge gained from PD/1 and PD/2. The final demonstration of PD/3 addressed the simulation of an air traffic control environment with demonstrated benefits for aircraft, with significant airspace capacity gains for the period 2005 -2015.

-74-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

The PD/3 Advanced Organisation

Main features of the Concept of the Advanced Organisation The Advanced Organisation is based on a concept of multi-sector planning, with the intention of evaluating potential capacity and economy improvements from traffic organisation, early planning and anticipated conflict resolution (deconflicting) through air/ground negotiation over a larger area and for larger look-ahead times. The concept is aiming at introducing the redistribution of workload from tactical controller to both PC and Multi-Sector Planner (MSP). The operational concept of the Advanced Organisation, as described in this document, alms to introduce a refinement of planning and deconfliction. From multi-sector planning down to the tactical phase of executive control, a continuously refined and updated air-ground contract negotiation process offers the advantages of precise trajectory prediction and thus the confidence in planning trajectories, combined with the flexibility of an adaptive system. The concept is based on improved knowledge via the intensive exchange of data between individual operating airborne and groundbased components of the ATM system. It applies the principle to adapt the planning, whenever a new optimum of traffic organisation and/or decrease of traffic situation complexity can be reached. Some of the conditions, considered as essential in order to be able to make the concept successful, are: Improvements, implemented in the PD/3 operational concept, concern: The planning philosophy: traffic organisation Since the human operator is remaining the key element of the air traffic control process, the management of trajectories in space and in time should remain compatible with ATCO skill and know-how so as to allow him to exercise his responsibility and his key role in the decision making process. The organisation of the trajectories in space and time should allow the controller to build and maintain a relevant representation and control of the traffic situation, which is required to perform his task at his level of intervention. The human being is in control of the operational process. A concept which evolves in an incremental way from the present ATM system. The capability to deal with mixed traffic situations and to provide a privileged status and The associated benefits to 4D controlled flights. A high capacity and flexible ATN system.

DOC 99-70-02

Version 1.0 / August 1999

-75-

Results

PHARE GHMI Project, Final Report

The Multi-sector planning concept

Due to the confidence attached to down-linked and contracted airborne trajectories, the scope of the planning activities can be enlarged over a period of 10 to 30 minutes ahead of the current aircraft position. From several organisations at first considered, involving a super-planner controller, replacing sector PC's and a multi-sector controller, strategically re-organising traffic, the present MSP concept has evolved. This MSP concept combines multi-sector strategy planning with planning at sector level. The multi-sector planning concept, aims at: Providing medium-term planning (30 minutes) for 4D controlled flights; Reducing traffic complexity in preparing trajectory modification to be implemented by the sectors either linked directly to equipped aircraft or to be implemented by TC sector for non-equipped aircraft. Balancing the sector's workload in redistributing traffic between sectors when appropriate; Optimising trajectories as appropriate.

And to enable the MSP to provide maximum benefit to a potential increase of capacity, to charge him with a specific task allocation: To optimise the trajectories on a systematic basis, whilst not increasing complexity, including direct routing and optimum level allocation to satisfy user preferred trajectories.

Note: it is the MSP's task, if appropriate, to overrule LOAs according to the analysis of the traffic situation. It is expected from the MSP actions to keep to a minimum the trajectory penalties imposed by LOAS. This is assumed to be achievable up to a certain complexity threshold. Beyond this, the action of the MSP will be to focus mainly on re-organising difficult traffic sequences and balancing the workload between sectors as appropriate. To intensively use the PRNAV aircraft capability with the aim of favouring the elaboration of parallel tracks and direct routes. To replan 3D aircraft in such a way that the TC will easily transmit verbally to the aircraft the MSP modifications. The changes should result in a as stable as possible situation reducing the need for vectoring and speed control. The actions for 3D aircraft are mainly limited to flight level change, direct to, and Offset tracks.

Note: this recommendation is also to be applied by the PC. The expected result is to demonstrate that a more natural way to control 3D aircraft than the pseudo 4D way is reducing workload of the TC and therefore is beneficial to 4D aircraft. The equipped aircraft are easy to reach by data link and it has to be prevented that equipped aircraft are manoeuvred around 3D aircraft. In that case it would result in an unintentional benefit for non-equipped aircraft (lesson learnt from PD/1).

-76-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Co-operative approach

As shown, in the PD/1 results, there is a need to improve the role of the controller team and work at sector level. The solutions, investigated in PD/3, are to integrate tools designed according to a cognitive engineering approach. This co-operative approach aims at: Preserving the controller's interest for the system: he will still be able to cope with the complexity and the variability of the control situations. Preserving the controller interest for his job: his creativity to face a new traffic situation and to elaborate relevant solutions. The objective is to avoid to move his activity to a supervision role which will induce loss of skill, poor traffic awareness and inability to cope with unpredicted events. Preserving the teamwork by introducing a common representation of the problem situation and computer assistance for an analysis of the traffic situation and a memorisation of identified problems, and the preparation and implementation of solutions.

Data-link for air-ground and ground-ground communications is the crucial element, which makes it possible to integrate the operations of airborne systems with groundbased ATC systems and to rely on the integration of ground-based ATC systems of different centres. In the next sections, some of the main features, concerning the data communication, are explained in more detail. Air-Ground communications philosophy in the Advanced Organisation of PD/3 The benefits of integration of operations of airborne and ground-based systems are derived from the use of data communication for: Information exchange Advanced control procedures

The exchange of information gives the background information for the accurate and consistent prediction capability on the ground and in the air. Advanced data-link information exchange processes inform the ground on short and medium-term aircraft flight intentions and informs the aircraft on e.g. more accurate meteorological conditions and about short and medium-term flight planning constraints. The most advanced process to control air traffic, is 4D control and negotiation. An essential feature of this Advanced Organisation is to apply a fully integrated process of air-ground and ground- ground co-ordinated dialogues via data-link, leading to trajectory contracts. The high accuracy of 4D prediction and 4D guidance supports enhanced computer assistance and working methods which will lead to increased capacity of the ATM system and enables the ATCO team to handle more aircraft simultaneously. At the same time, consistency and compatibility with different levels of equipment in mixed traffic situations is reached by full compliance of 4D guidance and control with short-term and tactical control processes. Unequipped aircraft shall be controlled by more tactical and more traditional procedures, using RT. lt is a requirement of the Advanced Organisation to offer the ATCO a GHMI capability which supports such compatibility. Look and feel behaviour of the GHMI in servicing aircraft either via 4D trajectory negotiation and/ or e.g. via RT, should be compatible and combined with efficient updating of the SPL.

DOC 99-70-02

Version 1.0 / August 1999

-77-

Results

PHARE GHMI Project, Final Report

Ground-Ground communications philosophy in the Advanced Organisation of PD/3 Advanced use of ground-ground communication and, related to this, an integrated ATM concept for planning and control is definitely required as complementary added functionality to air-ground integration. Exchange of surveillance and system flight plan data is required to support advanced functionality, e.g.: Trajectory prediction capability over a time period of up to 40 minutes. Consistency of the working of advanced tools, working over sector and centre boundaries with common representation of problem situation, conflict detection, advisory and conflict resolution capability. An advanced system to support executive control and planning activities, and, associated with this, an enhanced system of co-ordination options between team members, sectors and centres. Trajectory negotiation capability, exceeding the sector and centre limitations. Advanced traffic monitoring options (look ahead, flight path monitoring).

Nevertheless, in spite of an integrated ground-ground systems philosophy, at the same time ATM systems of different centres should be able to work independently of each other. This independence is required for reasons of robustness, fallback options and management requirements. Different ground systems should be able to work independent, to be able to rely on own process and task scheduling, on the processing of own tool sets, and on a complete, consistent and up-to-date flight plan database. Full consistency of data must be guaranteed based on own data validation tools and own consistency checks. The required independence of ground systems is reached, while achieving at the same time a maximum level of ground-ground integration, applying weak coupling between ground systems, combined with a frequent exchange of surveillance and flight plan status information.

-78-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Results

Results

The specification of a GHMI for such a complex system as pursued in PD3 proved to be quite an endeavour. Nevertheless, the GHMI design team produced an extensive specification under extreme high time pressure. However, implementation proved to be as difficult as the specification. As a consequence, the simulations had to be limited to fit the local capabilities of simulation systems. A similar problem as encountered during PD2. So, only two sites (CENA, NLR) realised a simulation, although with quite different characteristics. It has to be noted however, that these results were achieved in close collaboration with EEC. The general impression of the simulations is that the results of the earlier work in PD1 and PD2 are essentially replicated. So, controllers acceptance will increase as a function of exposure to new designs and an opportunity to train and work with new options. It is of interest that controllers proved to be able to be quite flexible in adapting to some, essentially different features as compared to their day to day work. The specific simulations will be discussed in some detail in the next sections.

DOC 99-70-02

Version 1.0 / August 1999

-79-

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.

THE CENA/PD3 GROUND HUMAN-MACHINE INTERFACE As established in PHARE, the GHMI was based on the HMI specifications of the GHMI group (especially the last delivered version 2.2). Refer to [1] for detailed information. Real furniture of the future French Operational CWP had to be used as depicted in Figure 33. Therefore, some adaptations had to be made in order to cope with its specific layout characteristics. The average distance between the main screen and ATCOs eyes necessitated a larger font size that in turn created problems with the available display space. Fortunately, the ancillary screen (21 inches) of this CWP could be used to enlarge the total surface area available. The sub-sections hereafter provide a short presentation of the Advanced GHMI. NOTE: the Baseline GHMI is not described here.

Figure 33: CENA Athis-Mons simulation facility (Controller Working Position)

DOC 99-70-02

Version 1.0 / August 1999

-80-

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.1.

EXAMPLES OF GHMI IMPLEMENTATIONS

Figure 34 En-Route GHMI (main screen)

DOC 99-70-02

Version 1.0 / August 1999

-81-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

Figure 35: En-Route GHMI (ancillary screen) The implementation for the ETMA and En-Route Controller Working Position in the Advanced Configuration is shown in Figure 34 and Figure 35. The main screen displays the Radar Image and Activity Predictor Display and the ancillary screen displays the Message In/Out Windows and the Profile Window. The configuration was made after having collected ATCOs inputs and feedback during the Pilot Phase.

-82-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.1.1. The main screen Radar Image: the current position of the aircraft, flight plan information through label or extended label. Sector Inbound List displays incoming aircraft at the border of the screen. Menus, Flight Legs allow the controller to change flight state, to input instructions, to display route. Main Menu allowing to change flight state (ASSUME, TRANSFER, etc ...) is in fact offered in any window where the callsign of an aircraft is displayed. A major part of the main screen is devoted to the Radar Image: it displays

This Radar Image is modal: i.e. filtering modes are either Problem oriented (selectable with Activity Predictor Display) or aircraft oriented (selectable through the Trajectory Editor and Problem Solving facility) are offered. Contrarily to what PD/1 proposed, the Highly Interactive Problem Solver facilities were now integrated in order to decrease the number of separated windows. The lateral window of the HIPS was directly integrated in the main Radar Image and a Time menu replaced the dedicated Speed Window, also directly available in the main Radar Image and in the Profile Window. Activity Predictor Display The APD provides a time axis; on the left side, ATC problems to be solved by the ATCOs are posted to the ultimate time of resolution; on the right side, advisory (ATC instruction) for non-equipped aircraft are posted to be issued just-on-time to Pilot. The APD was fully compliant with GHMI specifications except no global Look-Ahead facilities were implemented. Additional windows Radar toolbox and Clock window complete the main screen allowing to configure radar image (map, space layers) 6.1.2. The ancillary screen Message In / Out windows The Message Out Window collects the request for coordination issued by neighbouring controllers or important system messages. The Message In Window is a log of sent messages. Profile Window The Trajectory Editor and Problem Solving facility once activated displayed the vertical profile of the aircraft in a dedicated window: the Profile Window. Interaction zones are displayed by the Problem Solver; the controller may draw a new working trajectory combining vertical constraint (in this window), lateral constraints (in the Radar Image) and time constraint via Time Menu facility.

DOC 99-70-02

Version 1.0 / August 1999

-83-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

6.2.

T HE TMA DEPARTURE CWP

Figure 36: Departure GHMI (main screen) As shown in Figure 36, the right side of the Departure CWP GHMI was used for the Departure Manager Display; As for En-Route and ETMA position, Message In/Out Windows and Profile Window were set on the ancillary screen (as shown by Figure 35).

-84-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.2.1. The main screen Radar Image: A major part of the main screen is devoted to Radar Image: it displays the current position of the aircraft, and flight plan information through label or extended label; Sector Inbound List displays incoming aircraft at the border of the screen. Menus, Flight Leg allow the controller to change flight state, to input instructions, to display route. Main Menu allowing to change flight state (ASSUME, TRANSFER, etc.) is in fact offered in any window where the call sign of an aircraft is displayed. This Radar Image is also modal in this case: an aircraft oriented filtered mode is offered (selectable through the Trajectory Editor and Problem Solving facility). Also, the Highly Interactive Problem Solver facilities were integrated in order to decrease the number of separated windows: - the lateral window of the HIPS was directly integrated in the main Radar Image and; - the dedicated Speed Window was replaced by a Time menu available directly in the main Radar Image and in the Profile Window. Departure Manager Window This window figures out a double time axis in the middle and two columns each for the two runways available at Roissy / CDG ( 27 and 28 ). On each axis are presented label for arriving aircraft (dark label) and departing aircraft (coloured label). Each label is posted at time of either take-off either landing. A yellow horizontal bar marks current time. This tools allow to organise take-off sequences, pick-up additional flight plan information, CFMU time slot information, delays and all information related to sequence management. Additional windows Radar toolbox and Clock window complete the main screen allowing to configure radar image (map, space layers) 6.2.2. The ancillary screen Message In / Out windows

The Message Out Window collects the request for co-ordination issued by neighbouring controllers or important system messages. The Message In Window is a log of sent messages. Profile Window The Trajectory Editor and Problem Solving facility once activated displayed the vertical profile of the aircraft in a dedicated window: the Profile Window. Interaction zones are displayed by the Problem Solver; the controller may draw a new working trajectory combining vertical constraint (in this window), lateral constraints (in the Radar Image) and time constraint via Time Menu facility.

DOC 99-70-02

Version 1.0 / August 1999

-85-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

6.3.

INTEGRATION OF PHARE

ADVANCED T OOLS

The overall efficiency of the PD/3 concepts depends highly on the controller having appropriate computer assistance tools. PD/3, on a technical and organisational point of view, set a very high level of complexity compared to previous PHARE Demonstrations since, no less than 9 different PHARE Advanced Tools (PATs) designed by 5 different ATM research centres had to be integrated in up to 3 different simulation platforms. CENA PD/3 was the occasion to refine tools already designed for PD/1, such as the Trajectory Predictor, the Flight Path Monitor, the Conflict Probe, and the Problem Solver. Brand new tools were created (Departure Manager) or adapted (Negotiation Manager 1, Co-operative Tools) for this experiment. Two tools (Arrival Manager and Tactical Load Smoother) were not integrated because they were not part of the CENA PD/3 experiment (no ARRival position or MSP position). 6.3.1. Trajectory Predictor (TP) The role of the Trajectory Predictor is to predict the trajectory of an aircraft taking in account all known information. Compared to tools already in use in ACC, this new one is far more accurate, using a database of aircraft performance characteristics and capable to be enriched by downlinked aircraft trajectory. For sure, it is of major help for non equipped aircraft since all assistance provided to the controller will depend on its outcome and it is a fundamental tool because a lot of the overall behaviour of the system rely on it. The PHARE version of this tool was not integrated on the CENAs platform unfortunately; the PHARE version, faced some problems during very late integration phases jeopardising the demonstration; as a fallback solution, it was decided locally to use CENAs STRANGE version. Its algorithm was upgraded in order to make it compliant with PHARE TP and so to meet new 4D constraint requirements. NOTE: the ground TP was actually a different algorithm from the ones used in the Air borne part: the traffic generator used a specific one while the Multi Cockpit Simulator and the real aircraft used EFMS 6.3.2. Conflict Probe (CP) The CP in CENA PD/3 system was used for DEParture position in order to detect possible conflicts between 2 departing aircraft. This tool was in fact used internally by other tools as the Departure Manager in order to determine automatically the best SID trajectory, and as the Negotiation Manager to evaluate if a proposed trajectory, in case of a co-ordination, was conflict free or not. For En-Route and ETMA especially, Medium Term Conflict Detection was in fact devoted to Co-operative Tools; this new tool allows to have a better view of problem at stake and their position in time. The CP was also used for basic assistance in the Baseline Organisation.

1 The Negotiation Manager appeared in PD/2 but was severely redefined for PD/3 purposes.

-86-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.3.3. Flight Path Monitor (FPM) This tools checks every new aircraft position against the stored 4D trajectory; if a significant deviation is detected in any dimension, the FPM raises a deviation alert displayed on the GHMI. 6.3.4. Negotiation Manager (NM) The role of this tool is to manage communications between the different actors sharing the same information, mainly trajectory of an aircraft: it receives either Pilot Request or ATC sets of constraints and decide, using underlying tools such as CP and TP, to warn the right people in the right manner. This tool encompasses a threshold logic limiting the occasion where a controller should be warned by a change of trajectory. 6.3.5. Problem Solver (PS) The Highly Interactive Problem Solver is a tool which allows the controller to assess different solutions for solving a conflict: this tools gives the controller an immediate feedback (yellow or red zone appearing directly on the radar image and the vertical profile window) of what would be the consequences of a new manoeuvre for an aircraft (notion of What-If facility). The HMI implementation for CENA/PD3 prioritised the access to information and the desire to limit switch of use between the radar image and another tool especially for the Tactical controller; thus, the HIPS was directly integrated in the main radar image imposing this image to be modal while in HIPS operation. This was a major difference with PD/1 GHMI where lateral modification via the HIPS took place in a dedicated window. The Highly Interactive Problem Solver was, as in PD/1, coupled very tightly with the GHMI in order to obtain a reactive HMI. 6.3.6. Departure Manager (DM) This tool was evaluated for the first time in the framework of CENA PD/3 experiment. The DM task is to manage the different constraints which influence departure sequencing: CFMU slot constraint, operational rules which imposes delay between 2 take-off (because of wake vortex) and separation rules during climbing phases; it pursues the objectives to limit the delay between Scheduled Time of Departure and Estimated then Realised Time of Departure, and proposes to the controllers a sequence which makes the better use of available runways. Coupled with CP, it proposed automatically a conflict free SID procedure, if any, among the set of predefined SID and alternative SID trajectory registered by both ATC and companies.

DOC 99-70-02

Version 1.0 / August 1999

-87-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

6.3.7. Co-operative tools (CT) These tools encompass different functionality: at first, predicted trajectory issued from TP is reconsidered in order to match controller perception; at second, problem detection is processed aiming at gathering conflicts in Significant Traffic Unit: these problems are posted along the time axis of the Activity Predictor Display according to the priority of solving. Subsequent functionality allow the controller to filter the radar image focusing on a specific problem and performing look-ahead for the set of aircraft involved in the problem. The Co-operative Tools fulfilled their role for the En-Route position. On the contrary, due to an insufficient tuning, the Co-operative Tools had to be withdrawn from the ETMA position because the quality of problem detection was too poor. 6.4. M AIN LESSONS LEARNT The principle of computer assistance was well received by the controller: especially the integration of tools like Co-operative Tools and Highly Interactive Problem Solver on the En-Route Planning Controller position offered a powerful environment. On the Departure position, the first acquaintance of controllers with a Departure Manager created great interest. Some controllers stated they intend to ask for an indepth evaluation of this tool in a more realistic and short-term ATC environment. Recommendations extracted from CENA PD/3 experiment report state that, future ATM projects utilising (part of) PHARE concepts should: explore ways to simplify Air-Ground Trajectory Negotiation and propose at sector level, procedures which comply with time pressure (it could be derived from CPDLC or Formalised Clearance); especially explore ways to simplify trajectory edition; TEPS facilities often provoke an increase of ATCO workload; do everything to obtain responses time as short as possible, a reliable overall system as well as logical and clear responses of the system; limit automation to what can be without any doubt trusted by controller and provide co-operative system functions allowing the controller to remain the master of the system; benefit from the techniques used in the preparation of this experiment to teach controller trainees ; the use of a standalone HMI system for practice appeared worthwhile ; the directive method utilized to teach both working method and HMI was well accepted and allows to teach very futuristic concepts with a good level of mastering at the end.

-88-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.5.

GHMI DISPLAYS AND I NTERACTIONS On the one hand, a majority of controllers reported a positive feeling about the coding of many HMI objects when considered independently. For instance, a significant majority of controllers thought that coding of radar labels were quite efficient (logic and comprehensible) and allowed status of each aircraft to be clearly identified. However a common criticism was that the aircraft track and speed vector were scarcely visible. On the other hand a majority of controllers considered the way display of priority information was managed as insufficient and not obvious enough (common criticism was that some factors like SIL, labels overlapping and filtered views might hide sometimes important radar image information). The specific STCA presentation was rejected by a majority of controllers. They justified it by the too many false alarms and the chosen coding (too slow flashing notably). Questions regarding the central screen size and the choice of a second screen (19 inches) led to significant positive answers (controllers particularly appreciated presentation of the Profile Window in the second screen).Interacting with the system through the mouse has been generally considered as a suitable solution. However a general comment highlighted limits of this device when devoted to the use of menus. Many controllers experienced real problems particularly with the level menus (significant majority of them expressed that selecting an option in this menu was really uneasy) and strongly wished improvements on it or an introduction of parallel input devices such as a mini-keyboard. 6.5.1. TEPS/TST Comments on the TEPS in DISPLAY MODE indicated that controllers agreed it allowed a quick way to consult a specific trajectory or compare several ones. In other respects, a controller reminded that he would have appreciated the possibility to display several trajectories while editing one. A significant majority of controllers reported that they frequently used the TEPS in EDIT MODE as PC. Comments indicated that they performed as much as possible their planning activities and were de facto obliged to use the TEPS. It was logical to state an opposite trend for the TC position since the controllers instructions given during the training specified that TEPS in EDIT MODE was much more devoted to planning activities. Results were similar when controllers were asked if they used frequently the Profile Window. Trend was negative when considering TC position whereas a significant majority of controllers reported they frequently used the Profile Window in PC position. Opinions regarding the helpfulness of TEPS for avoiding conflicts diverged depending on the sector. Indeed, all the controllers from En-Route sector reported that they agreed or slightly agreed with this statement while TEPS was not seen in this light by a majority of controllers from ETMA and Departure sectors. Negative answers have been triggered by the feeling controllers had there were too many irrelevant bubbles (interaction zones). A majority of controllers judged that the TEPS was not useful for reducing workload. Common criticism was that even though the way conflicts were presented (bubbles) was globally well received, trajectory editing was far too long and complicated.

DOC 99-70-02

Version 1.0 / August 1999

-89-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

En-Route controllers clearly expressed that TEPS and TST facilities provided good conditions to well manage planning activities with non equipped aircraft and decomplexify the traffic. However the trend was opposite for ETMA controllers. Answers from Departure controllers were quite mixed. Comments indicated that positive feelings were mainly due to the possibility of resolving conflicts in advance while negative feelings were due to the lack of co-operation PC/TC which hampered the efficiency of planning actions. In others respects, a significant majority of controllers raised that TEPS facilities are useful in PC/TC co-operation only when supported by oral communication. Moreover, both PC and TC sometimes met some difficulties to build a clear awareness of each trajectory status. The following questions did not always give rise to a quick answer. Is it a conflict free trajectory? Is it a foreseen trajectory? Has something specific been changed by the PC? Is someone currently working on the trajectory of this aircraft or intending too? Opinions were quite mixed regarding the way TEPS and TST helped controllers to manage data-link exchanges with equipped aircraft. The excessive time demand (validation step or crew reaction) was, according to the controllers, the main factor to be improved. However, a significant majority of controllers reported that, in this context, their workload due to VHF communication was reduced. Considering response time of the Trajectory Edition, it appears that ATCO average time edition is between 20 and 40 seconds, which seems pretty long; moreover, the validation action (trajectory processing by the TP) required an additional delay of 7 second (minimum value is equal to 5s and maximum value is equal to 9s) even though Human Factors data generally recommend that a delay for getting an answer from a system should not exceed 2s. Considering trajectory negotiation the use of TEPS greatly benefited from the overall convenient environment provided by the TST support in all trajectory exchanges (including ground-ground exchanges between controllers or controller and system). Coding of trajectory and logic of TST was well understood. A marginal majority of controllers reported that, as PC, their workload due to telephone could be reduced by TEPS and TST facilities. It can be noticed that all the En-Route controllers positively answered to this question. However, opinions were quite mixed regarding the way the co-ordination with entry and exit sectors could be managed through the TEPS and TST facilities. Comments indicated that the principle of exchanging a trajectory can be full of promises but some incertitude - Is someone currently working on this aircraft? Has a something been changed on this trajectory by someone else? Can this facility substitute the telephone in case of emergency?

-90-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The CENA PD/3 GHMI

6.5.2. MIW/MOW In Baseline organisation, a majority of controllers (statistically significant for TC and trend for the PC) reported that they did not frequently used the MIW/MOW. Negative responses were all statistically significant (PC and TC positions) when considering the Advanced organisations. Whatever the organisation, a majority of them rejected the statement that the MIW/MOW were helpful for optimising co-ordination. Common comments raised that they were not enough alerted by an in-coming message and they did not really integrate the MIW/MOW in their visual checking. Some controllers added that just a sound signal would have correctly drawn their attention on those windows. The positioning of the ancillary screen could be a factor in these results as scanning is more complicated. Other comments indicated that messages were not enough explicit and often forced them to use the phone. Improvements of the MIW/MOW would be desirable for all the organisations. 6.5.3. CRD (used only in the Baseline environment) A majority of controllers reported that they did not use the CRD frequently in TC position. A majority of them (trend) also reported negative answers for PC positions. They appreciated the idea of providing a synthetic and dynamic view of conflicts but clearly criticised the fact that conflicts were most of the time non pertinent or affected another sector. They consequently estimated that the CRD was not useful for reducing their workload (statistically significant result). A majority of them (trend) justified it by the fact that information displayed in the CRD was not helpful for avoiding conflicts. Associated comments indicated that the display was quickly cluttered by obsolete conflicts that could not be removed from it and thus prevented them from efficiently check the CRD content. All the controllers thought that improvement in the CRD would be desirable for all the organisations. 6.5.4. SIL A majority of controllers stated (trend for TC and not significant result for PC) they did not use SIL frequently. However, controllers of en-Route and ETMA sectors2 expressed it could be useful for planning controllers rather than for tactical controllers. Comments indicated that information in SIL might be of interest for managing conflict in sector entry. However a significant majority of controllers reported that SIL was not highly relevant for their work and they all stated that improvement as follow could change their point of view: when presented on radar display, SIL should not in any way hide other information (e.g. radar labels) and present complete information on request like route details (the destination notably); when automatic removal event occurs, it should come with explicit fact that the associated aircraft has been fully integrated by the controller.

2 Departure positions were not provided with SIL

DOC 99-70-02

Version 1.0 / August 1999

-91-

The CENA PD/3 GHMI

PHARE GHMI Project, Final Report

6.5.5. Advisories labels in the APD3 Advisory labels in the APD aimed at helping TC to organise his control activity and to give prepared instructions just in time. Feeling about this depended on the sector. Indeed negative and positive opinions were balanced in En-route sector whereas all the ETMA controllers gave a negative one. A common criticism was that advisories messages were often without operational sense (incorrect or concerning another sector) and it led the controllers to mistrust those messages. Hence, a significant majority of them wished improvements in the advisory labels information. 6.5.6. Departure Manager A positive issue can be raised regarding overall information that was provided by the DM display. DEP PC appreciated the clear and synthetic view of pre-departure traffic pattern: the overall ground sequence on each runway, the occupation balance between both runways and the precise configuration of aircraft that were about to takeoff (this last one was also appreciated by DEP TC). Animation features implemented in order to produce a smooth feedback of what the system or the ATCO did, appeared as a useful tool in order to give a better awareness of what happened and especially, discovery of error. If tactfully implemented, they really improve exchange between Man and Machine.

3 Departure positions were not provided with APD

-92-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI project, Final Report

This page left intentionally blank

-93-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

7. 7.1.

THE NLR/ PD3 GROUND HUMAN-MACHINE INTERFACE AIRSPACE AND OVERVIEW GHMIS Valid PD/3 sector configurations in the NLR experiment were: Multi-Sector, En-Route (ER), Area Control Centre (ACC), Arrival (ARR) and Departure (DEP). Within these sectors there are roles of tactical and/or planning, depending on the sector definition. The following sector{xe "sector"} configurations and the associated GHMIs have been used: En-Route(ER) Sectors: Maastricht Brussels West ACC Amsterdam ACC-South Amsterdam RIVER Stack ARR Amsterdam TMA Feeder Sectors: En-Route (ER) Maastricht South Maastricht Delta ACC Amsterdam ACC-North/East Amsterdam ACC-North/West Brussels ACC Amsterdam ARTIP Stack Amsterdam SUGOL Stack Planner and Tactical Planner and Tactical Tactical Planner and 2 Tacticals 2 GHMIs 2 GHMIs 1 GHMI 3 GHMIs

1 GHMI 1 GHMI 1 GHMI 1 GHMI 1 GHMI 1 GHMI 1 GHMI

The NLR PD/3 GHMI contained, in contrast with the CENA configurations, separate graphical interfaces (windows) for the Highly Interactive Problem Solver. All sector{xe "sector"} configurations have the HIPS interface, but only the TMA sectors have the AMD. The airspace is defined as the grouping of sector{xe "sector"}s that are controlled by those air traffic controllers that are being measured for the experiment (even though in the PD/3CT no measurements were made in the end). These sector{xe "sector"}s comprise the Schiphol TMA, the Amsterdam Radar South ACC sector and the Maastricht Brussels West sector. Error! Objects cannot be created from editing field codes.

DOC 99-70-02

Version 1.0 / August 1999

-94-

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

7.2.

EXAMPLES OF GHMI IMPLEMENTATIONS 7.2.1. ACC and TMA working positions

Figure 37: ACC planner GHMI with radar window, highly interactive problem solver window and a conflict risk window.

DOC 99-70-02

Version 1.0 / August 1999

-95-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

Figure 38: TMA GHMI radar window

-96-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

7.2.2. Arrival Manager Display (BaseAMD) There were two main versions of the Base AMD, configured as follows: For the TMA sectors, the BaseAMD provides a tabular list of all inbound aircraft sorted by arrival runway and then time at the arrival runway gate. For the ACC sectors and STACK positions, the BaseAMD provides a tabular list of all inbound aircraft coming via the Metering Fix in the sector/stack, sorted by time at the Metering Fix.

The information displayed in the BaseAMD is derived from data received from the BaseAM and available in SPLs.

Figure 38: AMD GHMI

DOC 99-70-02

Version 1.0 / August 1999

-97-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

7.2.3. Vertical View Display (VVD) The Vertical View Display (VVD) is available to controllers in a number of different sectors. Each PD/3 Organisation requires slight differences in VVD, in addition to the SPL data being held in different parts of the SPL, configured as follows: In the Baseline Organisation, the VVD is present in all ACC sectors and all STACK sectors related to the appropriate Metering Fix. The important SPL data concerning flight times are contained solely in the SPL tube list. In the Advanced Organisation, the VVD is only presented in the STACK sector{xe "sector"}s related to the appropriate Metering Fix. The important SPL data concerning flight times is contained in the SPL predict list.

Figure 39: Holding area

-98-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

7.3.

ROLES AND WORKING PROCEDURES In the PD/3CT advanced organisation a number of roles were defined. These are: En-route Planning Controller: En-route Tactical Controller: ACC Planning Controller: ACC Tactical Controller : Arrival Sequence Planner: TMA Tactical Controller: Stack Controller: Feeder Controller: ER-PC ER-TC ACC-PC ACC-TC ARR-SP TMA-TC SC FC

Each role comprises a number of tasks that need, or can, be executed. Below some examples are provided for roles and their associated tasks. Tasks are triggered by certain events. These events are described including their representation to the controller. The function of a task is to achieve a certain objective. This objective also delineates the completion of the task. In order to fulfil the task a number of actions have to be taken. These actions are described especially where they contain interactions with the ATC system. It may also be that these actions result in new events that trigger other tasks with either the same or other controllers. Examples of such resulting events are also described. This description model is compatible with the Task Logic Diagrams used in the definition of the PD/3 GHMI specification. The following model has been used by the engineers to implement and realise the complex GHMI in software.
Task Action2 Event Action1 Action4 Action3 End Condition Achieved

Event

Figure 40: The software implementation model describing controller tasks

DOC 99-70-02

Version 1.0 / August 1999

-99-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

7.3.1. Aircraft states Many of the tasks of the various roles are related to the state in which aircraft can be. These states are directly related to the colour coding of the aircraft labels on the GHMI. The state of an aircraft depends on the sector{xe "sector"}. For each sector an aircraft can have only one state. The state of an aircraft can however differ between sector A and sector B. The following five states are used: Not Concerned State Aircraft that will never be of concern to the sector{xe "sector"} (or never again). An aircraft that is deemed to be NOT CONCERNED, shall be: - an aircraft that will not enter the relevant sector, or - an aircraft that has permanently exited the sector. Information on these aircraft (Radar Label) can be selectively filtered out from the controllers display with the height filter. Not Yet Plannable State An aircraft shall be classified as in the NOT YET PLANNABLE state until it enters the planning authority of the position. These are aircraft for which it is possible to perform planning changes. Advanced Information state shall indicates that the interaction with the aircraft is permitted (i.e. the controller has the Planning Authority for this aircraft). At the same time when an aircraft is converted into the Advanced Information State, the label on the giving sector displays the next sector name in the NS field. NOTE: it is possible that this Advanced Information can be made available earlier by the use of the FORCED ACT option on the Callsign Menu by the previous sector. Assumed State These aircraft are on frequency and have been assumed, i.e. they are under the sectors current control. This concerns aircraft that are no longer under Authority or Control but remaining physically within the Sector. Traffic that has been released, or traffic that has been transferred out but which has not yet physically left the sector.

Advanced Information State

Concerned State

-100-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

The changes of state for each aircraft are mostly automatic. There are a number of exceptions: Any planning controller may request early planning authority by using an input to the system. This forces the concerned aircraft from Not Yet Plannable State in Advanced Information State. Unequipped aircraft are manually assumed and released by the tactical controller of a sector{xe "sector"}. This concerns the change from Advanced Information State to Assumed State and from Assumed State to Concerned State.

7.3.2. En-route Planning Controller Role The planning role of the ER PC is to anticipate the evolving traffic situation in order to ensure efficient organisation of traffic through the sector{xe "sector"}. This is done by assessing and resolving traffic planning conflict situations. The ER-PC mainly aims to resolve these planning conflicts but occasionally leaves problems to be assessed and/or solved by the tactical controller in a later stage. Flights are planned after acquisition of Planning Authority. The PCs can co-ordinate with any PC of a giving or receiving sector on flight plan updates. Most of this coordination is performed implicitly and silently via the system. The ER-PC also has the role to assist the ER-TC in controlling the aircraft that are already under control of the sector. Tasks The following tasks are to be carried out by the ER-PC: - The ER PC shall analyse the flight information so as to integrate the flight into the traffic situation. - The PC shall monitor the traffic for deviations from the planning and when necessary he shall re-plan the aircraft. - The PC shall resolve planning conflicts as much as possible before the concerned aircraft are taken under control by the sector. - The PC shall co-ordinate alternative plans with adjacent sectors if activation would create a planning conflict. The ER-PC is responsible for the handling of aircraft down-linked trajectories. The PC is responsible for the co-ordination with adjacent sectors for aircraft that are in the Advanced Information State . The Planning Controller shall support the Tactical Controller when necessary. The PC shall support the TC in monitoring aircraft that have been released to the next sector but that are still in their sector. The PC shall co-ordinate with the TC when necessary. The PC shall co-ordinate with adjacent sectors when called.

DOC 99-70-02

Version 1.0 / August 1999

-101-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

Below, three of such tasks of the ER-PC are described following the model described earlier. Task Number: ERPC_1 Task description Trigger event Trigger representation

The ER PC shall analyse the flight information so as to integrate the flight into the traffic situation. Aircraft state changes from Not Yet Plannable to Advanced Information. The trigger is visualised in a number of ways on the GHMI: The label colour changes to pink (and if the aircraft will change level in the sector additional information is displayed in the label)

An entry is made in the Sector Inbound List

Sequence of actions

A message is presented in the message in window

As a result of the trigger the following actions are/can be taken by the ER-PC: The ER-PC assesses the information related to the flight in order to update his mental picture of the situation If there are one or more planning conflicts detected by the system and indicated on the GHMI for this particular aircraft the ER-PC continues with the task of resolving a planning conflict (see below).

End condition(s)

The task is completed when the plan for the aircraft to cross the sector{xe "sector"} is acceptable to the control team (i.e. in principle conflict free).

-102-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Task Number: ERPC_2 Task The PC shall monitor the traffic for deviations from the planning and when description necessary he shall re-plan the aircraft. Trigger event Trigger representation Aircraft deviates from plan The trigger is visualised on the GHMI in the following way: A yellow marker circle is displayed around the position symbol of the aircraft

Sequence of actions

As a result of the trigger the following actions are/can be taken by the ERPC: He assesses whether the aircraft is in Advanced Information State or Assumed State. If the aircraft is in Advanced Information State it is under control of another sector{xe "sector"} and the deviation is not yet relevant to this controller. He may however still decide to update the planning for this aircraft to reflect the deviation from the current plan. If the aircraft is in Assumed State , it is in principle the responsibility of the TC to get the aircraft back to the plan. If the TC decides that replanning is the best solution he may delegate this task to the ERPC. If the aircraft is already close to the exit of the sector it may also be decided to co-ordinate the need for replanning with the PC of the next sector. If the PC has to update the planning he starts by loading the flight plan into the HIPS, clicking with the right mouse button on any representation of that aircrafts callsign on the GHMI. He then assesses the need to modify any constraint based on the aircrafts active plan, the deviation and the traffic situation. (He has to make at least one modification to generate a new flight plan context for that aircraft, which can then be activated). When he is finished making modifications to the constraints he can generate a new trajectory prediction by bringing up the Trajectory Support Tool and selecting the validate option. When the trajectory is generated and no planning conflicts are introduced by it, he can activate the new plan. Whenever a new planning conflict is created in an adjacent sector between the alternative plan and any existing plans, this triggers the need to co-ordinate

End condition(s)
DOC 99-70-02

The task is completed when a new plan has been activated which takes into account the deviation form the previous plan.
Version 1.0 / August 1999 -103-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

Task Number: ERPC_3 Task description

The PC shall resolve planning conflicts as much as possible before the concerned aircraft are taken under control by the sector{xe "sector"}. A planning conflict is detected The trigger is visualised in a number of ways on the GHMI: A conflict symbol is created on the Conflict Risk Display (CRD), also indicating the callsigns of the aircraft concerned.

Trigger event Trigger representation

The exit port in the labels of the concerned aircraft change colour to yellow. (only if the aircraft is either in the Advanced Information State or the Assumed State ) (The label below is also inverted because it is selected)

The exit port in the SIL changes colour to yellow.

-104-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Sequence of actions

As a result of the trigger the following actions are/can be taken by the ER-PC: He assesses whether the aircraft are in Not Yet Plannable State, Advanced Information State or Assumed State . He identifies the aircraft for which he intends to change the plan. This aircraft can not be in the Not Yet Plannable State. If the aircraft is in Advanced Information State he loads its active flight plan in the HIPS by clicking with the right mouse button on any callsign of this aircraft on the display (so either in the label, in the CRD or in the SIL).

If the aircraft is in the Assumed State it is the responsibility of the ER-TC to resolve the problem. He may however delegate this to the ER-PC. The ER-PC then modifies one or more constraints, thereby creating an alternative set of constraints. The HIPS display interface allows the controller to interactively see the effect of his changes on the conflict situation.

DOC 99-70-02

Version 1.0 / August 1999

-105-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

When he is finished making modifications to the constraints he can generate a new trajectory prediction by bringing up the Trajectory Support Tool and selecting the validate option.

When the trajectory is generated and no planning conflicts are introduced by it, he can activate the new plan.

-106Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Whenever a new planning conflict is created in an adjacent sector{xe "sector"} between the alternative plan and any existing plans, this triggers the need to co-ordinate (see Error! Reference source not found.) If a planning conflict is detected in the sector that the PC is responsible for, he has the option to modify the constraints further, or to force the plan to become active, despite the planning conflict. After any co-ordination has been completed or after the PC has forced the new plan to become active, the system identifies the need to negotiate the new plan with the aircraft. Only if the aircraft is equipped, will a negotiation be initiated.

End condition(s)

The task is completed when the conflict is eliminated from the active system plans.

DOC 99-70-02

Version 1.0 / August 1999

-107-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

7.3.3. En-route Tactical Controller Role The controlling role of the ER TC is to make sure that the aircraft adhere as much as necessary to their planning. Flights are controlled after acquisition of Control Authority, i.e. when the aircraft has changed to the Assumed State. Tasks The following tasks are to be carried out by the ER-TC: Task Number: ERTC_1 Task description

The ER TC shall maintain traffic situation awareness and be ready to intervene with tactical clearances in the event of unexpected conflict or urgency situations. Control of an equipped Aircraft is assumed automatically by the system (Note: The pilot of such an aircraft does not have to call in on the R/T). The trigger is visualised in a number of ways on the GHMI: The colour of the aircraft label changes to White when the aircraft is automatically assumed by the sector.

Trigger event

Trigger representation

Sequence of actions

The entry for the aircraft is removed from the SIL. A message is presented in the message in window???

This task does not consist of a number of specific actions that must be performed when the trigger occurs. However, the ER-TC will normally as a result of the trigger perform the following action: He will assess the aircraft plan, initially through its label information, to adjust his mental picture of the traffic situation and to anticipate possible future actions. He may also assess the flight plan in more detail by looking at the Augmented Dynamic Flight Leg (ADFL) or the Extended Label Window (ELW).

End condition(s)

The task is completed when the aircraft is transferred to the next sector (i.e. it changes to the Concerned State )

-108-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Task Number: ERTC_2 Task description

The ER TC shall maintain traffic situation awareness for aircraft that are no longer under his control responsibility but are still in his sector. An equipped Aircraft changes to the Concerned State or a non equipped aircraft is released within the sector. The trigger is visualised in a number of ways on the GHMI: The label of the aircraft is presented in the concerned colour (Mustard)

Trigger event Trigger representation

Sequence of actions

A message is presented in the message in window

As a result of the trigger the TC takes no particular actions. He will however keep monitoring the concerned aircraft against other flights. The task is completed when the aircraft actually leaves the sectors airspace and changes to the Not Concerned State.

End condition(s)

DOC 99-70-02

Version 1.0 / August 1999

-109-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

Task Number: ERTC_3 Task description Trigger event Trigger representation

The ER-TC shall manually assume control of a non equipped aircraft. Such an aircraft is released by the previous sector{xe "sector"} and the pilot of the aircraft calls in on the R/T. The trigger is presented in a number of ways: The pilot of the aircraft calls in to the sector using its R/T frequency. On the GHMI the representation of the callsign in the label of the aircraft is changed to the assumed colour (White). If the aircraft has not been assumed by the sector before the aircraft actually enters its airspace a box will be drawn in assumed colour (White) around the label as a reminder.

Sequence of actions

As a result of the trigger the following actions are/can be taken by the ER-TC: After matching the aircrafts R/T callsign with the information on the screen the TC will assess the need for any immediate action for this aircraft. He will respond to the aircrafts call by confirming the identification and if necessary by giving it a clearance. When moving the mouse pointer in the label presentation on the RPVD, the label will be presented in filled-in mode. He will assume control of the aircraft by clicking with the left mouse button on any representation of this aircrafts callsign on the GHMI.

After clicking with the left mouse button on the ASSUME button, the aircraft is assumed and the whole label will be presented in assumed colour (White).

End condition(s)

The task is completed when the TC has assumed control over the aircraft

-110-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

7.4.

INTEGRATION OF PHARE ADVANCED T OOLS 7.4.1. Trajectory Predictor (TP) There were three types of TP Server in PD/3, configured as follows: Main TP to generate the first trajectory for aircraft (For PD/3 : non-4D datalinkequipped only); Air-TP version with multiple instances for use by the Air Traffic Server; Alternative TP version with multiple instances for use by the SPL Server;

Generation of a trajectory by the PATs TP software requires the input of aircraft state data plus a set of constraint data, which details departure, route and arrival details. The data structures used for input to the PATs TP are defined in CMS, so they required mapping software to translate to and from NARSIM defined data. 7.4.2. Flight Path Monitor (FPM) The PATs FPM monitors radar track data against the active SPL data for each aircraft every radar cycle. The PATs FPM monitors for the following: Deviation Creation, Update and Deletion events are produced to indicate an aircraft deviating outside of the planned tube given in its active SPL. Deviation from the planned tube is given in terms of transversal, longitudinal, altitude and time deviations. The planned tube for an aircraft is calculated along with the trajectory the tube for a non-4D datalink-equipped aircraft will be larger than for an equipped aircraft. Ground-Supported Navigation Advisory (GSNA) An event is produced to indicate that an aircraft is deviating from its planned tube, but by following the given advisory, the aircraft will be able to re-enter its planned tube. This advisory given in the event is used to pre-empt a potential deviation when a tactical command has not been given or manoeuvre not executed. Significant Point Passed An event is produced to indicate that an aircraft has passed a significant point. The subscription mechanism for this event allows another server/client to specify a combination of aircraft identity and significant point. This allows specific points in an aircraft's SPL to be monitored. For PD/3 at NLR this function has not been used by any other system component than the GHMI server. 7.4.3. Conflict Probe (CP) There were a number of instances of the CP used, which consisted of two types a main CP and multiple Alternative CPs. Main CP The main CP function is to probe for conflicts against all Active SPLs. The CP server subscribes to receive all Active SPLs and whenever a new or updated Active SPL is received, the CP probes it against the Active SPLs of all other aircraft. The CP server maintains a database of conflicts creating, updating and deleting them as appropriate.

DOC 99-70-02

Version 1.0 / August 1999

-111-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

If called directly to perform a probe on an Alternative SPL, this version of the CP will probe the Alternative against the Active SPLs of all other aircraft. The server will not store any conflicts found, but will return an indication of the conflicts (if any) to the caller. Alternative CP(s) To help spread the processing load of the Negotiation Manager, a multiple number of Alternative CPs was required to perform the one-off probing of an Alternative SPL. To achieve this, this instance of the CP still had to subscribe to receive and hold the data on all Active SPLs but this instance of the CP did not perform any probing for conflicts whenever a new or updated Active SPL was received. Probing of Alternative SPLs for conflicts is performed in the same way as described above for the Main CP. The Negotiation Manager server maintains a list of available Alternative CPs from whom to request this service. 7.4.4. Arrival Manager (AM) The PATs AM performs the sequencing and scheduling for arrival traffic for a specific airport (or configuration of runways). A graphical display window is available to the ATCo's concerned with arrival sequencing that display data available from the AM. Interaction with the graphical interface results in sequence change input to the AM, which provides updated sequence data to reflect the input. 7.4.5. Negotiation Manager (NM) The NM provides a central managing component to control all ground-ground coordination and all air-ground co-ordination. Whenever another component (e.g. GHMI or AM) has generated an alternative SPL which they want to register, the NM will be instructed to perform a negotiation on the alternative SPL. There will be five sorts of negotiation that the NM allows: Request Negotiation This is the normal way to conduct a negotiation, with a component requesting the NM to check an Alternative SPL to see if a ground-ground co-ordination is required. If it is, the NM will send an event to the appropriate party(s) so that it can check the SPL. At this point the whole negotiation can be cancelled, counterproposed or accepted. After any ground-ground co-ordination is complete, the NM will perform an air-ground negotiation on 4D datalink-equipped aircraft. At the end of a successful air-ground negotiation or for non-4D datalink-equipped aircraft after a successful ground-ground co-ordination the NM will activate the SPL. Forced Negotiation This option allows a component to override any ground-ground co-ordination and go straight on to the air-ground negotiation. For a non-4D datalink equipped aircraft, this will just activate an SPL. Formalised Clearance this option is available to components with tactical control of an aircraft to override normal co-ordination and negotiation protocols. For a 4D datalink equipped aircraft, this will mean an instruction to the pilot and onboard TP to fly as best as possible according to the up-linked set of constraints and start flying straight away. For a non-4D datalink-equipped aircraft this will mean to activate the trajectory generated from the set of constraints as quickly as possible.

-112-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Aircraft Proposal (4D datalink-equipped aircraft only). This option allows a pilot to propose a new trajectory to the ground. The NM will determine which (if any) components need to be informed about the proposal for their consideration. Should the trajectory pass the co-ordination filters, the trajectory will be accepted automatically. Only after approval from the ground-system will the aircraft be allowed to fly the proposed trajectory. If the proposal causes conflicts or other problems it can also be cancelled or counter-proposed by the appropriate ground-system components.

Pre-emptive Downlink (4D datalink-equipped aircraft only). This option has not been used in PD/3 at NLR, but is intended to indicate some sort of emergency problem for the aircraft, for which the pilot has down-linked a trajectory to indicate what is now being flown e.g. a missed approach.

In addition to controlling the co-ordination and negotiation processes, the NM is also used to test alternative SPLs to indicate if any co-ordination is required. This is used by the GHMI to provide visual indications about an alternative SPL that an ATCo is editing. The results of such a test is also used to dictate which form of negotiation the GHMI will allow through its graphical interface. 7.5. T HE AIRCRAFT HMI The aircraft was equipped with the experimental FMS. In adition to that, a modified Primary Flight Display was implemented. That display followed the tunnel in the sky format. This particular format is quite compatible with the PHARE concept of a conflict free bubble in the sky. The tunnel will depict both the planned (and cleared) route, including the limits of the bubble. Alerting functions will alarm the crew when deviations or trends towards potential deviations occur. Combined with the navigation display different look ahead times can be served and both displays provide ample opportunity to build a traffic awareness when other aircraft are also displayed. Such a display can be generated through the ground- air datalink (slow update) or air-air datalinks like ADS-B (high update rate).

DOC 99-70-02

Version 1.0 / August 1999

-113-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

Figure 41: The cockpit of the NLR Citation aircraft with the Airborne Human Machine Interface The use of such displays is still experimental and opinions on its benefits are under debate. One example is the effect on visual workload. Its is well known that synthetic displays can be quite compelling and could absorb visual attention to undesired levels. For that reason, experiments were performed at NLR to measure the actual workload. The used equipment included point of gaze (eye tracking) measurements. An example of a display format with superimposed eye fixations and transitions is depicted below.

Figure 42: Experimental tunnel or bubble in the sky format, with superimposed eye fixation and transition data. Simulator experiment. For information, contact the NLR. Data obtained in several flight simulator experiments suggested that the opposite is in fact more likely. The results of a comparison with the traditional PFD seemed to favour the new design. An example of the results is depicted below.

Eye fixations / minute

70

Conventional PFD
60

50

40

Tunnel type display


30

before
Auto pilot failure

after

-114-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

The NLR PD/3 GHMI

Figure 43: Visual workload as indicated by eye fixations needed for two conditions: normal and after an auto pilot failure. 7.6. M AIN LESSONS LEARNT The building of such a complex working environment is quite a challenge. Several controller teams used the resulting system simultaneously and it was a great reward to all the designers that, after some time, the room became quite and the atmosphere relaxed, as it actually proved possible to actually control quite high levels of traffic. However, just as in the CENA study, the limitations of computing power limited the response times of tools. For any GHMI, swift system responses are critical. An additional replicated or consistent effect was that the dialogue of trajectory negotiation is still complex and fairly cumbersome. With all the new information and tools, a simplification should be realised. This seems feasible, as the original designs were compliant with existing procedures. Already in PD1 it was discovered that transferring existing conventions to new designs is not by definition effective. A similar lesson was learned with respect to the glass cockpits where dials designs on computer screens were not always as compliant as expected. So, these effects seem to be part of a natural evolution process. During the design phase, too novel features are deemed as potentially unacceptable and the design is aimed at a transition. However, when the new possibilities come to life, experience can be gained and the potential fully exploited. Therefore, these designs provide excellent playgrounds for reconfiguring, studies and optimisation. A second lesson learnt is that training proved quite essential and instrumental in enabling controllers to cope and adjust their controlling strategies to the new environment. Due to the time pressures involved, the training material needed, such as screen dumps of GHMI components was not available in time. Therefore the training designers had to improvise and create their own pictures, simulations etc. As a consequence, deviations or differences from the final system could occur and such a phenomenon will reduce training effectiveness. Some controllers, who had experience from earlier PHARE demonstrations, complained that, although their previous experience helped them in getting familiar with the system, differences with the old system were not always adverted. Clearly, highlighting such (essential) differences was not yet possible in the scope of the present project. Despite the material available, the system went into full operation in a matter of days (or hours of training) indicating that transitions to a PHARE like system could be manageable and achievable. Optimised and tested training material will clearly assist in such transitions. 7.7. GHMI DISPLAYS AND INTERACTIONS 7.7.1. Trajectory display (Dynamic Flight Leg Display) With respect to the trajectory display, a vast majority of the controllers were convinced that the trajectory display functionality was useful in resolving conflicts and the colours used were easy to understand and use. Modifying a trajectory using the tools provided proved to be difficult for just over half of the controllers. From controller remarks it appears that 3D aircraft deviating from their planned trajectory increased the workload significantly and that in the TMA planning by trajectory management was difficult due to the high traffic loads.

DOC 99-70-02

Version 1.0 / August 1999

-115-

The NLR PD/3 GHMI

PHARE GHMI Project, Final Report

7.7.2. TST The Trajectory Support Tool (TST) turned out to be useful in simplifying co-ordination and was easy to use for the majority of the controllers. Use of the co-ordination tool proved to be difficult for some controllers, more seriously was the fact that for most controllers it was not clear with whom they were coordinating. In addition, the reason for co-ordinating was not clear for everyone. Two controllers explained the reasons why co-ordination was not easy quoting the system to refuse accepting seemingly sound resolutions, not receiving any responses from other controllers when trying to co-ordinate changes and the system requiring coordination when according to the controller this was not required. 7.7.3. Labels Label (and overall) colour coding was appreciated by most controllers. The planning status of an aircraft was clear for all but one controller although a remark was made that the system sometimes did not update the planning status correctly. 7.7.4. CRD Controller opinions on the usefulness of the conflict risk display in avoiding conflicts were very much divided. From the remarks it appeared that CRD reliability was not too high (according to some controllers the CRD sometimes failed to identify losses of separation whereas in some cases conflicts indicated did not appeared to be conflicts). In addition one controller remarked that a high number of conflicts shown on the CRD made it difficult to use the CRD. When accessing flight details, controllers preferred selecting the aircraft label as opposed to the Conflict Risk Display or Sector Inbound List (SIL). The SIL was not used frequently, especially not in busy airspace. Identifying the 3D or 4D capability of an aircraft was not easy for many controllers. 7.7.5. HIPS From the three methods of resolving problems (lateral, level and time control), time control proved to be the most difficult one to use. One controller remarked that due to the (small) size of the specific sector it was not able to use time control. Lateral control seemed to be acceptable but the acceptance of level control showed widely divided controller opinions. From controller remarks, issues with level control seem to be conflicts being displayed when controllers were convinced of sufficient separation between two aircraft.

-116-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Discussion

8. 8.1.

DISCUSSION
THE DESIGN PROCESS

8.1.1. The specification format The specification format changed and evolved during the work itself. In PD1 there was a close relation between the GHMI team and the software developers that led to a mutual understanding of the issues to be resolved. In that situation, text was sufficient to allow the software designers to do their work. In later parts of the project, tasks were carried out more independently. The main reason for this was due to the fact that parts of the programme were overlapping. So, some of the GHMI team members were still processing data from PD1, while others were specifying the PD2 GHMI. This limited the opportunities for multi-disciplinary interaction as resources became more scarce and management issues more prominent. One improvement that facilitated the process was the use of task-logic diagrams (sometimes in the form of state-transition matrices). These describe the input/output relations between system components and their timing. So, PATS tools designers could more easily modify the software to fit the overall configuration. Other improvements made were the inclusion of summary tables of functionality in the specification. Also, summaries of colour coding, basic mechanisms etc. were added. With such assistance, the software designer can have more easy access to the specification. However, the software specialist still had to study and absorb the total material to decide on the most efficient coding strategy. The material proved to be so vast, that no single designer was able to absorb all details. Better or more compatible formats have to be developed. An alternative is to make a better use of prototyping facilities with dirty coding. Smaller scale experiments are possible and the lessons learnt will allow a more reduced specification that contains high confidence HMI utilities. Unfortunately, the available prototyping tools were not really flexible enough to assist such a process. Response times fall down as a function of new elements added that are not a part of the regular library. As a consequence the first hard coded PD1 software had to be re-used, altered, extended etc. If a team is available that knows such software extensively, coding can still be efficient. If such a team is not available, matters are much more complex. An example of a specification of a GHMI element (the Arrival Predictor Display) is provided in the annex. A high level discussion on specification issues is also available in the annex.

DOC 99-70-02

Version 1.0 / August 1999

-117-

Discussion

PHARE GHMI Project, Final Report

8.1.2. The evaluation process The reliance on subjective ratings and personal appreciations of controller working positions has been reduced by the development of more objective means for assessing human performance and strategies in using the GHMI. Measures such as eye-scanning and other psycho-physiological parameters proved essential in understanding why certain behaviours occurred. These measures proved very useful during the exploratory experiments but were not applied during the main demonstrations. Several reasons existed. Firstly, the use of such measures requires specialists and advanced equipment only available for one of the partners. The pressure of the demonstrations is so high that the responsible parties tend to adopt a strategy of scope reduction and that immediately affects the quality of the evaluation and the tools used for that. Furthermore, some of the techniques used were still experimental and not yet proven, thereby reducing the willingness to incorporate them beforehand. Still a lot of useful data has been obtained and processed. It could have been much more if the experiments were conducted on a smaller scale first, in stead of going for the full world in one go. However, smaller scale experiments tend to raise questions to be resolved first, thereby making it more difficult to plan the big demonstrations. What the best strategy will be, has to be decided in follow-on projects. One aspect is however very clear. The PHARE programme has resulted in ATM systems that include many facilities that can be re-used effectively for further investigations. The equipment and procedures for more objective validations has also been proven and is ready for future use. 8.1.3. Controller acceptance Initially, controllers were quite sceptical about the use of a windowing environment and other facilities that seemed to drag the design away from a traditional radar display. However, when time passed and more and more controllers gained experience with the designs in realistic simulations, acceptance increased. The factor of hands-on experience seems instrumental in gaining such acceptance. The emphasis on the simulations seems more than justified, based on this argument. The international collaboration proved very supportive in allowing may controllers access to the system, allow exchange of experiences and tips for improvements, resulting in a invented by us attitude. Clearly, it has been a project with intensive multi-disciplinary interactions that really helped in getting advanced ATM off the ground. As a result, many of the PHARE GHMI elements now integrated in the new EATCHIP baseline design and the United States FAA has raised considerable interest in adopting the design for its own purposes. Also, ATC providers within PHARE have already performed some additional experiments to tailor and improve the design. So there have been PD1 plus and PD2 plus experiments. The results are available, but the work was an extension of the initial designs and not an integral part of the core GHMI project. Some participants in the programme even felt a bit left out of such, in itself positive, follow-on actions. Such a development should be better co-ordinated if controller acceptance is to be gained at a more European or even global level.

-118-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Discussion

In general, the project can be regarded as successful in gaining controller acceptance. Adequate exposure, participation and experience gained through the available training material seem to have been major factors in accomplishing these positive results. Training should never be underestimated, as additional training could possibly ameliorate the phenomena of high traffic panic. The training tools available in the programme were not part of a full scope, training project. They can be compared with band-aids for problems noted during the development process. These band-aids were effective, but future programmes should include training analysis and design from the very beginning. 8.2.
HUMAN FACTORS ISSUES

8.2.1. Changing roles in teams The first results already indicated very clear that the 4D planning concept could be performed effectively by the planner controller. As a result the tactical controller had little or nothing left to do. As controllers are highly motivated to provide the best available service, the tactical controllers sometimes intervened. The result was that the planning was disrupted causing confusions and leading to additional team work. Some even argue that a tactical is not required anymore and that the resources freed, could be used for other purposes. Clearly, studies in such a direction seem promising in the light of a possible reduced availability of controller candidates in the future. The availability of the PHARE technologies can be effectively used to study the feasibility and effectiveness of new role sharing. 8.2.2. Responses to high traffic loads A critical note on the effectiveness of tools and GHMI can be made based on observations on controllers strategies under (very) high traffic loads. Under high traffic volumes, controllers tended to revert to their basic nature with respect to strategy and working methods. Under pressure, typically the centre of the screen is monitored and the controller is concentrating on particular aircraft. The tools, that were designed to assist especially under such conditions, are not used anymore! This phenomenon has been denoted as the high traffic panic response. It is noteworthy to mention that controllers are most often unaware of this change in strategy. Objective behaviour data indicates that level of experience is a mediating factor in deciding at which particular traffic load this behaviour will be initiated. More work is required to study this effect in more detail as it poses a risk for the transition to future systems as well as their effectiveness in the long end. 8.2.3. Situational awareness A side effect of the attention tunnelling mentioned in the previous section is that the overall traffic awareness can be reduced. The big picture is still a highly appreciated concept and the impact of advanced tools and working methods are yet poorly understood. Therefore some risks are still present that have to be dealt with. Especially the high traffic load conditions, the role of training etc. need more work.

DOC 99-70-02

Version 1.0 / August 1999

-119-

Discussion

PHARE GHMI Project, Final Report

A second issue is that a change in roles could also extend to the working methods. One option mentioned was to create a direct link between the aircraft trajectory generation system and the ground based conflict probe. The controller would only be involved in case of a conflict, and not when there are no implications for overall traffic conflicts. In such a case, the basis for a big picture could brake down leaving the controller in a reactive mode in stead of a proactive mode. For many reasons such a method can be beneficial but it will increase the dependencies on the advanced tools. More validation studies are in need to guarantee that such systems would comply with a certification standard of ATM (that is still non-existing).

-120-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Conclusions

9. 9.1.

CONCLUSIONS
THE DESIGN GOALS

It can be concluded that the GHMI actually reached its original design goals. The designs were completed in time and did not delay the overall project schedule. The controllers who worked the prototypes gave us confidence that many of the principles and guidelines proposed by GHMI will be adopted in the new generation of HMIs. Clearly, research will be needed to refine the present designs and improve them where required. The obtained data with these designs revealed that overall workload was indeed reduced to such levels that some of the controllers actually were left with little to do. This was not an intended result, but partly a consequence of the focus on more advanced planning functions, a core element of the PHARE concept. The initial strategy of GHMI was to design a generic, multi-purpose controller working position that allowed the controllers to adopt multiple working methods. With such a design, this result, of leaving little left for the tactical controller, could emerge spontaneously. It subsequently served as an input for a renewed discussion on future staffing and transition requirements for ATM systems. 9.2.
CONTROLLER SKILLS

Based on the overall results within the programme, it still seems feasible to configure the systems in such a way that the transition from older to newer systems can be accomplished without major difficulties. One way could be to design update packages that include a subset of the tools. Controllers would be allowed to gradually absorb the potential of the new tools before going to a next update. Additional studies are clearly indicated on this issue. However, if all the potential of advanced technologies has to be exploited, major changes in roles and working methods cannot be excluded. So, the expectation for that case is that controller skills will never be the same as before. The availability of the option for gradual transitions by re-configuring into subsets could positively influence the feasibility of an acceptable transition or expansion of such skills. However, we realise that PHARE focussed on the nominal situation. Much work needs to be performed on the non-nominal conditions, before actual implementation can be pursued.

DOC 99-70-02

Version 1.0 / August 1999

-121-

PHARE GHMI Project, Final Report

This page left intentionally blank

-122-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Recommendations

10. 10.1.

RECOMMENDATIONS FUTURE USE OF RE- CONFIGURABLE TOOLS AND GHMI The PHARE technologies and simulation platforms seem to provide a unique opportunity to investigate possible future configurations. Modifications can be made fairly easy and its impact on controller performance and safety investigated. Issues like non-nominal conditions were not yet included and clearly need attention. It has to be realised that all tools and technologies have not been fully validated. They were designed and used effectively, but in limited scenarios not yet using the full complexity of possible traffic patterns. PHARE provides the necessary harmonised platforms capable of performing this very essential work.

10.2.

ATM DEVELOPMENTS : AIRBORNE OPPORTUNITIES One of the obvious critical point on the ground based 4D concept, is that it is not realistic to expect that all countries will be able to update to such an advanced system, let alone all in the same time. Aircraft would have to operate in both low tech and high tech ATM systems. The disadvantages need no explanation. An airborne-based capability is therefore quite attractive as airlines directly feel the benefits all over the world. However, the 4D concept seems to have essential benefits that are as good or at least complementary to the functions of airborne-based systems. A best of both worlds approach seems in order to adequately cover low and very high traffic density areas. Exploratory studies in such direction indicate that such a marriage could be feasible and beneficial (Hilburn et. al. 1998)

10.3.

AND THE FUTURE. The work was completed, but it is not finished! Experiments are in need to learn about impact on controller behaviour, traffic awareness and ASAS. Non nominal conditions need validation. Training issues need to be explored further.

DOC 99-70-02

Version 1.0 / August 1999

-123-

PHARE GHMI project, Final Report

This page left intentionally blank

-124-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Acknowledgements

11.

ACKNOWLEDGEMENTS None of this work would have been possible without the excellent willingness to cooperate on a European scale. The work has been tough but very rewarding for most, if not all participants. We would like to express our deepest respect and appreciation for all those hardworking men and women.

DOC 99-70-02

Version 1.0 / August 1999

-125-

PHARE GHMI project, Final Report

This page left intentionally blank

-126-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Glossary, List of Acronyms

12.

GLOSSARY, LIST OF ACRONYMS

ACRONYM AAS ACC ACC-PC ACC-TC ADFL AERA AHMI AM AMD APD APP APP ARR SP ATC ATCO ATM BaseAMD BaseAM CENA CFMU CLW CMS CP CPDLC CRD CT CWP CZW DEP DEP TC DFS DLR DM
DOC 99-70-02

Meaning Advanced Automation System Area Control Centre ACC Planning Controller AAC Tactical Controller Augmented dynamic flight leg Automated En Route Air Traffic Control Airborne Human Machine Interface Arrival Manager (PATs) Arrival Management Display Activity Predictor Display Approach Centre Approach Sector ARRival Sequence Planner Air Traffic Control Air Traffic Controller Air Traffic Management Base Arrival Manager Display Base Arrival Manager Centre dEtudes de la Navigation Arienne (France) Central Flow Management Unit communications list window Common Modular Simulator Conflict Probe (PATs) Controller Pilot Data Link Communications, (an air-ground D/L application) Conflict Risk Display Cooperative Tools (PATs) Controller Working Position conflict zoom window DEParture controller DEParture Tactical Controller Deutsche Flugsicherung GmbH Deutsche Forschungsanstalt fr Luft- und Raumfahrt (Germany) Departure Manager (PATs)
Version 1.0 / August 1999 -127-

Glossary, List of Acronyms

PHARE GHMI Project, Final Report

ACRONYM DRA EATCHIP EATMS EFMS ER ER PC ER TC ETMA FAA FC FPM GHMI GRIGRI GSNA HAW HIPS HMI ICP MIW MMI MOW MSP NARSIM NLR ODID OTF PATs PD PD/1 PD/2 PD/3 PHARE PRORES PROSIT PS
-128-

Meaning Defence Research Agency (UK) European Air Traffic Control Harmonisation and Integration Programme European Air Traffic Management System Experimental Flight Management System En-Route En-Route Planner Controller En-Route Tactical Controller Extended Terminal Manoeuvring Area Federal Aviation Administration (USA) Feeder Controller Flight Path Monitor (PATs) Ground Human Machine Interface project Gestures, Recognition on Interactive Graphical Radar Images Ground-Supported Navigation Advisory Horizontal Assistance Window Highly Interactive Problem Solver (PATs) Human Machine Interface Internal Clarification Project Message In Window Man-Machine Interface Message Out Window Multi-Sector Planner NLR ATC Research Simulator Nationaal Lucht- en Ruimtevaartlaboratorium (Netherlands) Operational Display and Input Development Operational Task Force (PD/3) PHARE Advanced Tools PHARE Demonstration PHARE Demonstration 1 PHARE Demonstration 2 PHARE Demonstration 3 Programme for Harmonised Air Traffic Management Research in EUROCONTROL PROblem RESolution PROblem SITuation Problem Solver (PATs)
Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI Project, Final Report

Glossary, List of Acronyms

ACRONYM PVD R/T RTO RWY SC SIL SPL STCA STU SWIFT TC TC-APD TDB TEPS TLX TMA TMA-TC TP TPDR TST VAW VHF

Meaning Plan View Display Radio / Telephony Ready for Take Off Runway Stack Controller Sector Inbound List System Plan Short Term Conflict Alert Selected Trajectory Update Specifications of Working position in Future Air Traffic Control Tactical Controller Tactical Controller Activity Predictor Display Track Data Block Trajectory Editor and Problem Solver (NAA) Task Load Index Terminal Manoeuvring Area/ Terminal Control Area TMA Tactical Controller Trajectory Predictor (PATs) Transponder Trajectory Support Tool Vertical Assistance Window Very High Frequency

DOC 99-70-02

Version 1.0 / August 1999

-129-

PHARE GHMI project, Final Report

This page left intentionally blank

-130-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

13.

RECOMMENDED LITERATURE Amaldi, P. (1994). Cognitive processes during the management of real air traffic scenarios . Paper presented at the First Conference on Cognitive Science in Industry. September, 1994: Luxembourg. Andre, A.D., Heers, S.T. & Cashion, P.A. (1995). Effects of workload preview on task scheduling during simulated instrument flight. International Journal of Aviation Psychology. 5(1), 5-23. Arad, B.A. (1964). The controller load and sector design. Journal of Air Traffic Control. May, 12-31. Bainbridge, L. (1987). Ironies of automation. In J. Rasmussen, K. Duncan & J. Leplat [Eds.], New technology and human error. (pp. 271-283). New York: Wiley. Barnes, M. & Grossman,J. (1985). The Intelligent Assistant Concept for Electronic Warfare Systems . China Lake, California: NWC December (NWC TP 5585). Baron, J. (1988). Thinking and Deciding . Cambridge, UK: University Press. Beatty, J. (1982). Task-evoked pupillary responses, processing load, and the structure of processing resources. Psychological Bulletin , 1982, 1(2), 276-292. Bell, D. (1982). Regret in decision making under uncertainty. Operations Research, 30, 961-981. Bergeron, H. & Heinrichs, H. (1994). A training approach for highly automated ATC systems. Journal of Air Traffic Control, June, 10-16. Billings, C. & Woods, D. (1994). Concerns about adaptive automation in aviation systems. In M. Mouloua and R. Parasuraman [Eds.] Human Performance in Automated Systems: Current Research and Trends . Hillsdale, New Jersey: Erlbaum. Billings (1991). Human Centered Automation: A Concept and Guidelines. NASA Technical memorandum 103885. Moffett Field, California: NASA Ames Research Center. Bisseret, A. (1981). Application of signal detection theory to decision making in supervisory control. Ergonomics, 24(2), 81-94. Bisseret, A. (1971). Analysis of mental processes involved in air traffic control. Ergonomics, 14(5), 565-570. Boehm-Davis, D., Curry, R.E., Wiener, E.L., & Harrison, R.L.(1983). Human factors of flight-deck automation: Report on a NASA industry workshop. Ergonomics, 26, 953-961. Boff, K.R. & Lincoln, J.E. (1988). Engineering Data Compendium: Human Performance and Perception . Volume I. WrightPatterson Air Force Base, Ohio: Armstrong Medical Research Laboratory. Boswell, S.B., Andrews, J.W. & Welch, J.D. (1990).

DOC 99-70-02

Version 1.0 / August 1999

-131-

Recommended Literature

PHARE GHMI Project, Final Report

Analysis of the Potential Benefits of Terminal Air Traffic Control Automation (TATCA). In Proceedings of the American Control Conference, pp. 535-542. Bradshaw, J.L. (1968). Load and pupillary changes in continuous processing tasks. British Journal of Psychology, 59, 265-271. Braven, W den and Have, JM ten(1990). NARSIM: A Real-Time Simulator for Air Traffic Control Research . NLR TP 90147 U. National Aerospace Laboratory NLR, Amsterdam. Broadbent, D. (1971). Decision and Stress. London: Academic Press. Brookings, J.B. & Wilson, G.F. (1994). Physiological and workload changes during a simulated air traffic control task. In Proceedings of the Human Factors and Ergonomic Society, 38th Annual Meeting . Brown, S.J. (1987). The challenges of future ATC automation and airspace. In Proceedings of the Fourth International Symposium on Aviation Psychology. (pp. 186-189). Columbus, Ohio: Ohio State University. Bulloch, C. (1982). Cockpit automation and Workload reduction: too much of a good thing? Interavia , 3,263-264. Cardosi, K. M & Murphy, E.D. (1995). Human Factors in the Design and Evaluation of Air Traffic Control Systems . DOT/FAA/RD95/3, Cambridge, Massachusetts: U.S. Department of Transportation, Volpe Research Center. Casali, J. & Wierwille, W. (1983). A comparison of rating scale, secondary task, physiological, and primary task workload estimation techniques in a simulated flight task emphasizing communications load. Human Factors, 25, 623-642. Costa, G. (1993). Evaluation of workload in air traffic controllers. Ergonomics, 36(9), 1111-1120. Cox, M. (1992). Report on the Cognitive Aspects of the Air Traffic Control Task . Report IAM 706. Farnborough, Hampshire, UK: Royal Air Force Institute of Aviation Medicine. Craig, A. (1992). Vigilance and monitoring for multiple signals. Performance. London: Taylor & Francis. In D.L. Damos [Ed.], Multiple Task

Credeur L. & Capron W.R., (1989). Simulation Evaluation of TIMER, a Time-Based, Terminal Air Traffic, Flow-Management Concept. NASA tech paper 2870, Hampton, Virginia: NASA Langley Research Center Curry, R.E. (1985). The Introduction of New Cockpit Technology: A Human Factors Study . (NASA TM 86659). Washington, DC: National Aeronautics and Space Administration. Curry, R.E. (1979). Mental load in monitoring tasks. In N. Moray [Ed.] Mental Workload: Its Measurement and Theory. New York: Plenum Press. Damos, D. (1992). Dual task methodology: some problems. In D.L. Damos [Ed.], Multiple Task Performance. London: Taylor & Francis.

-132-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Danaher, J.W. (1980). Human error in ATC system operations, Ergonomics, 22(5), 535-545. Delle, H.J. van, Aasmen, J., Mulder, L.J.M. & Mulder, G. (1985). Time domain versus frequency domain measures of heart rate variability. In J.F. Orlebeke, G. Mulder & L.J.P. van Doornen [Eds .], Psychophysiology of Cardiovascular Control: Models, Methods, and Data . New York: Plenum Press. Dreyfus, H.L. & Dreyfus, S.E. (1986). Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer. The Free Press. Eggemeier, F.T. (1988). Properties of workload assessment techniques. In M. Venturino [Ed.] Selected Readings in Human Factors. (1990) (pp. 228-248). Santa Monica, California: Human Factors Society. Endsley, M.R. & Rodgers, M.D. (1994). Situation awareness requirements for en route air traffic control. In Proceedings of the Human Factors and Ergonomics Society, 38th Annual Meeting . Nashville Tennessee, October 24-28. Endsley, MR (1994). A taxonomy of situation awareness errors. Proceedings of the Western European Association for Aviation Psychology, 21st Conference. March 1994-- Dublin, Ireland. Endsley, M. R. (1992). Situation Awareness: A Fundamental Factor Underlying the Successful Implementation of AI in the Air Traffic Control System. Paper presented at the NASA/FAA workshop on AI and HF in ATC and av. maintenance. Daytona Beach,Florida, June 1992. Endsley. M (1993). Situation awareness and workload: flip sides of the same coin? In Proceedings of the 7th International Symposium on Aviation Psychology, Columbus, Ohio. Ephrath, A.R., & Young, L.R. (1981). Monitoring versus man-in-the-loop detection of aircraft control failures. In J. Rasmussen & W.B. Rouse [Eds .], Human Detection and Diagnosis of System Failures (pp. 143-154). New York: Plenum. Ericsson, K.A. & Simon, H.A. (1984). Protocol Analysis: Verbal Reports as Data . Cambridge, Massachusetts: MIT Press. Ertzberger, H. (1992). CTAS: Computer Intelligence for Air Traffic Control in the Terminal Area . NASA Technical Memorandum 103959. Moffett Field, California: Ames Research Center. Fisher, D.F., Monty, R.A., and Senders, J.W. (1981). Eye Movements: Cognition and Visual Perception. Hillsdale, New Jersey: Erlbaum. Flach, J. (1994). Situation awareness: the emperor's new clothes. In M. Mouloua & R. Parasuraman (Eds.) Human Performance in Automated Systems: Recent Research and Trends. (pp. 242-248). Hillsdale, New Jersey: Erlbaum. Fuld, R.B., Liu, Y., & Wickens, C.D. (1987). The impact of automation on error detection: Some results from a visual discrimination task. In Proceedings of the Human Factors Fociety, 31st Annual Meeting (pp. 156-160).

DOC 99-70-02

Version 1.0 / August 1999

-133-

Recommended Literature

PHARE GHMI Project, Final Report

Gawron, V.J., Schiflett, S.G. & Miller, J.C. (1989). Measures of in-flight workload. In R.S. Jensen (Ed.) Aviation Psychology . Brookfield, Vermont: Gower. Gopher, D. & Donchin, E. (1986). Workload: An examination of the concept. In K.R. Boff, L. Kaufman, & J.P. Thomas [Eds.]. Handbook of Perception and Human Performance (Vol II, chap. 41). New York: John Wiley and Sons. Gosling, GD (1987). Identification of artificial intelligence applications in air traffic control. Transportation Research, vol. 21A, no.1, pp 27-38. Gosling, GD & Hockaday, SLM (1984). Identification and Assessment of Artificial Intelligence Techniques in Air Traffic Control. Research report UCB-ITS-RR-84-14, Institute for Transportation Studies, U of California, Berkeley, California. Systems Research, Georgia Institute of Technology. Green, D.M. & Swets, J.A. (1966). Signal Detection: Theory and Psychophysics . New York: Wiley. Hancock, P.A. & Chignell, M.H. (1988). Mental workload dynamics in adaptive interface design. IEEE Transactions on Systems, Man, and Cybernetics, 18(4), 647-658. New York: Institute of Electrical and Electronics Engineers. Harris, R.L., Glover, B.L., & Spady, A.A. (1986). Analytic Techniques of Pilot Scanning Behavior and Their Application. NASA technical paper 2525. Harris, W.C., Hancock, P.A., & Arthur, E. (1993). The effect of taskload projection on automation use, performance and workload. Proceedings of the Seventh International Symposium on Aviation Psychology. Columbus, Ohio: Ohio State University. Hart, S. & Wickens, C.D. (1990). Workload assessment and prediction. In H.R. Booher [ed.] MANPRINT: An Emerging Technology, Advanced Concepts for Integrating People, Machine, and Organization. New York: Van Nostrand Reinhold. Hart, S.G. (1990). Pilots' workload coping strategies. In Challenges in Aviation Human Factors: the National Plan. pp.25-28. American Institute of Aeronautics and Astronautics. Hart, S.G. & Hauser, J.R. (1987). Inflight application of three pilot workload measurement techniques. Aviation, Space and Environmental Medicine . May, 402-410. Hart, S.G. & Stavelend, L.E. (1988). Development of the NASA-TLX (Task Load Index): results of empirical and theoretical research. In P.A. Hancock & N. Meshkati [Eds.] Human Mental Workload . Holland: Elsevier. Harwood, K (1994). CTAS: an alternative approach to developing and evaluating advanced ATC automation. In M. Mouloua and R. Parasuraman [Eds.] Human Performance in Automated Systems: Current Research and Trends. Hillsdale, New Jersey: Erlbaum. Harwood, K (1993). Defining human-centered issues for verifying and validating air traffic control systems. In JA Wise, VD Hopkin & P Stager [Eds.] Verification and Validation of Complex Systems: Human Factors Issues. Berlin: Springer-Verlag.

-134-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Hawkins, F.H. (1993). Human Factors in Flight. Brookfield, Vermont: Ashgate. Hendy, K.C., Hamilton, K.M., & Landry, L.N. (1993). Measuring subjective workload: when is one scale better than many? Human Factors, 35(4), 579-601. Heppenheimer, T.A. (1995). Turbulent Skies: The History of Commercial Aviation. New York: Wiley. Hess, E.H. (1975). The Tell-Tale Eye . New York: Van Nostrand Reinhold. Hess, E.H. (1965). Attitude and pupil size. Scientific American , April, 46-54. Hess, E.H. & Polt, J.M. (1964). Pupil size in relation to mental activity during simple problem solving. Science, 1964, 143, 1190-1192. Hilburn, B., Parasuraman, R. & Mouloua, M. (1995). Effects of short- and long-cycle adaptive function allocation on performance of flight-related tasks. In N. Johnston, R. Fuller & N. McDonald [Eds.], Aviation Psychology: Training and Selection. Hampshire, England: Ashgate Publishing. Hilburn, B., Singh, I., Molloy, R., & Parasuraman, R. (1992) Training and Adaptive Automation: Non-adaptive Feedback Training. Technical report CSL N92-1, Cognitive Science Laboratory. Hockey. G. (1986). Changes in operator efficiency. In K. Boff, L. Kaufman, & J. Thomas (eds.) Handbook of Perception and Performance (vol II). New York: Wiley. Hopkin, V.D. (1996). Automation in air traffic control: recent advances and major issues. Proceedings of the Second Automatioin Technology and Human Performance Conference. Orlando, Florida: University of Central Florida. Hopkin, V.D. (1980). The measurement of the air traffic controller. Human Factors , 22(5), 547-560. Hopkin, V.D. (1979). Mental workload measurement in air traffic control. In N. Moray [Ed.] Mental Workload: Its Measurement and Theory. New York: Plenum Press. Hopkin, V.D. (1991). The impact of automation on air traffic control systems. In J. A. Wise et al. [Eds.], Automation and Systems Issues in Air Traffic Control. Berlin: Springer-Verlag. Hopkin, V.D. (1989) Man-machine interface problems in designing air traffic control systems. In Proceedings of the IEEE, 77(11), November 1989, pp 1634-1642. New York: Institute of Electrical and Electronics Engineers. Hopkin, V.D. (1994). Human performance implications of air traffic control automation.In M. Mouloua and R. Parasuraman [Eds .] Human Performance in Automated Systems: Current Research and Trends. Hillsdale, New Jersey: Erlbaum. Houselander, P. & Owens, S. (1995). An Initial Assessment of the Effects of a Number of Computer Assistance Tools upon Controller Workload. CS Report 9503. London: Civil Aviation Authority.
DOC 99-70-02 Version 1.0 / August 1999 -135-

Recommended Literature

PHARE GHMI Project, Final Report

Hughes, D. (1989). Glass cockpit study reveals human factors problems . Aviation Week and Space Technology. August 7, 32-36. Hunt, V.R. & Zellweger, A. (1987). Strategies for future air traffic control systems. Computer , February 1987, 19-32. Hurst, M.W. & Rose, R.M. (1978). Objective job difficulty, behavioral response, and sector characteristics in air route traffic control centres. Ergonomics, 21, 697-708. ICAO (1996). Civil Aviation Statistics of the World, 1995 . Montreal, Quebec, Canada: International Civil Aviation Organization. ICAO (1993). Increased ATC automation may be inevitable to handle increasing traffic and data. ICAO Journal, June 1993, pp. 16-20. Montreal, Quebec, Canada: International Civil Aviation Organization. Idaszak, J.R. (1989). Human operators in automated systems: The impact of active participation and communication. Proceedings of the Human Factors Society 33rd Annual Meeting . Idaszak, J.R. & Hulin, C.L. (1989). Active Participation in Highly Automated Systems: Turning the Wrong Stuff into the Right Stuff . Technical report ARL-89-7/ONR-89-1, Champaign, Illinois: University of Illinois, Institute of Aviation. Israel, J.B., Chesney, G.L., Wickens, C.D., & Donchin, E. (1980). P300 and tracking difficulty: evidence for multiple resources in dual-task performance. Psychophysiology. 17(3), 259-272. Jex, H.R., & Clement, W.F. (1979). Defining and measuring perceptual-motor workload in manual control tasks. In N. Moray [Ed.], Mental Workload: its Theory and Measurement. pp. 125-178. New York: Plenum Press. Johannsen, Pfendler & Stein (1976). Human performance and workload in simulated landing-approaches with autopilot-failures. In T. Sheridan and G. Johannsen [Eds.], Monitoring Behavior and Supervisory Control. New York: Plenum. Jones, R.E., Milton, J.L. & Fitts, P.M. (1949). Eye Fixations of Aircraft Pilots. USAF Technical report 5837, US Air Force. Jordan, N. (1963). Allocation of functions between man and machines in automated systems. Journal of Applied Psychology, 47(3). Jorna, P.G.A.M. (1991). Operator workload as a limiting factor in complex systems. In J.A. Wise [Ed.] Automation and Systems Issues in Air Traffic Control. Berlin: Springer-Verlag. Jorna, P.G.A.M. (1993). The human component of system validation. In JA Wise, VD Hopkin & P Stager [Eds.] Verification and Validation of Complex Systems: Human Factors Issues. Berlin: SpringerVerlag. Kahneman, D. (1973). Attention and Effort. Englewood Cliffs, New Jersey: Prentice Hall. Kahneman, D., Slovic, P. & Tversky, A. (1982). Judgment under Uncertainty: Heuristics and Biases . New York: Cambridge University Press.
-136Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Kalsbeek, J.W.H. (1976). Some Aspects of Stress Measurement in Air Traffic Control Officers at Schiphol Airport. Symposium on stresses of air traffic control officers (University of manchester, Dept. of postgraduate medical studies), 39-42. Kantowitz, B.H & Casper, P. (1988). Human workload in aviation. In E.L. Weiner & D.C. Nagel [Eds.], Human Factors in Aviation. pp 157-187. San Diego: Academic Press. Keinan, G. (1987). Decision making under stress: scanning of alternatives under controllable and uncontrollable threats. Journal of Personality and Social Psychology. 52(3), 639-644. Kim, W., Zangemeister, W. & Stark, L. (1984). No fatigue effect on blink rate. In Proceedings of the Twentieth Annual Conference on Manual Control, vol. 2, p 337-348. Moffett Field, California: Ames Research Center. Kirlik, A. (1993). Modeling strategic behavior in human-automation interaction: Why an aid can and should go unused. Human Factors , 35, 221-242. Klein, G.A. (1993). A recognition-primed decision (RPD) model of rapid decision making. In G.A. Klein, J. Orasanu, R. Calderwood & C.E. Zsambok (Eds .), Decision Making in Action: Models and Methods (pp. 138-147). New Jersey: Ablex Publishing. Klein, G.A. (1989). Recognition-primed decisions. In Advances in Man-Machine Systems Research , Vol. 5, 47-92. JAI Press, Inc. Kramer, A.F. (1991). Physiological metrics of mental workload: a review of recent progress. In D.L. Damos [Ed.], Multiple Task Performance . London: Taylor & Francis. Krebs, M.J., Wingert, J.W. & Cunningham, T. (1977). Exploration of an Oculometer-Based Model of Pilot Workload . NASA technical report CR145153. Minneapolis, Minnesota: Honeywell Systems & Research Center. Lee, D.H. & Park, K.S. (1990). Multivariate analysis of mental and physical load components in sinus arrhythmia scores. Ergonomics, 33(1), 35-47. Leighbody, G., Beck, J., & Amato, T. (1992). An operational evaluation of air traffic controller workload in a asimulated en route environment. 37 th Annual Air Traffic Control Association Conference Proceedings (pp. 122130). Arlington, Virginia: Air Traffic Control Association. Lenorovitz, D.R. & Phillips, M.D. (1987). Human factors requirements engineering for air traffic control systems. In G. Salvendy [Ed.] Handbook of Human Factors , New York: Wiley. Leplat, J. (1978). The factors affecting workload. Ergonomics, 21, 143-149. Leroux, M. (1993). The PATS cooperative tools. In Proceedings of the Scientific Seminar on PHARE. Braunshweig, Germany: DLR Institute for Flight Guidance. Liu, Y., Fuld, R. & Wickens, C.D. (1993). Monitoring Behavior in Manual and Automated Systems. In International Journal of ManMachine Studies, 39, 1-15.
DOC 99-70-02 Version 1.0 / August 1999 -137-

Recommended Literature

PHARE GHMI Project, Final Report

MacLennan, R.N. & Peebles, J.W.E. (1996). Survey of health problems and personality in air traffic controllers. International Journal of Aviation Psychology, 6(1), 43-56. Madni, A.M. (1988). The role of human factors in expert system design and acceptance. Human Factors, 30, 395414. McDaniel, J. (1988). Rules for fighter cockpit automation. In Proceedings of the IEEE National Aerospace and Electronics Conference . pp. 831-838. New York: Institute of Electrical and Electronics Engineers. Meckliff,C and Gibbs, P (1993). PATs problem solver. In PHARE Forum: Scientific Seminar of the Institute for Flight Guidance of DLR. Eurocontrol. 6-8 October, 1993. Meshkati, N., Hancock, P.A. & Rahimi, M. (1990). Techniques in mental workload assessment, in J.R. Wilson & E.N. Corlett [Eds .]. Evaluation of Human Work: A Practical Ergonomics Methodology . London: Taylor & Francis. Michiels, R. (1994). An Overview of the NLR ATC Research Simulator NARSIM. NLR Technical Paper 94341L, Amsterdam, the Netherlands: National Aerospace Laboratory NLR. Mogford, R.H. (1994). Cognitive Engineering: The Importance of the Air Traffic Controller's Mental Model. Unpublished manuscript. Mogford, R.H., Murphy, E.D., Roske-Hofstrand, R.J., Yastrop, G. & Guttman, J.A. (1994). Research Techniques for Documenting Cognitive Processes in Air Traffic Control: Sector Complexity and Decision Making. Report DOT/FAA/CT-TN94/3. Pleasantville, New Jersey: CTA Incorporated. Mooij, H.A. (1995). Point of Gaze Measurement in Aviation Research . Paper presented at the 79th Symposium of the Aerospace Medical Council, 23-27 April, 1995. Brussels, Belgium. Moray, N. (1979). Models and measures of mental workload. In N. Moray [Ed.] Mental Workload: Its Measurement and Theory. New York: Plenum Press. Moray, N. (1967). Where is capacity limited? A survey and a model. Acta Psychologica, 27, 84-92. Mosier, Heers, S., Skitka, L. & Burdick, M. (1996). Patterns in the Use of Cockpit Automation. In Proceedings of the Second Automation Technology and Human Performance Conference. Orlando, Florida: University of Central Florida. Muir, B.M. (1987). Trust between humans and machines, and the design of decision aids. International Journal of Man-Machine Studies, 27, 527-539. Molloy, R., Deaton, J. & Parasuraman, R. (1996). Monitoring for automation failures using the EICAS display: effects of adaptive allocation on automation. In Proceedings of the Second Automation Technology and Human Performance Conference. Orlando, Florida: University of Central Florida.

-138-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Murphy, E.D. & Cardosi, K.M. (1995). Issues in ATC automation. In Cardosi, K. M & Murphy, E.D. (eds.). Human Factors in the Design and Evaluation of Air Traffic Control Systems . DOT/FAA/RD-95/3, Cambridge, Massachusetts: US Department of Transportation, Volpe Research Center. Nagel, D.C. (1988). Human error in aviation operations. In E.L. Weiner & D.C. Nagel [Eds.], Human Factors in Aviation, pp 263-304. San Diego: Academic Press. National Public Radio (1992). February 25 broadcast, Morning Edition, transcript. Washington, DC: Author. NATO (1994). Psychophysiological Assessment Methods. Advisory Group for Aerospace Research and development (AGARD), Advisory Report 324. Neuilly Sur Seine, France: NATO AGARD. Nijhuis, H.B. (1993). A Study Into the Consequences of Data-Link for the Mental Workload of the Air Traffic Controller. PHARE draft document. Brussels: Eurocontrol. Nolan, Michael S. (1990). Fundamentals of Air Traffic Control. Belmont, California: Wadsworth. Nordwall, B.D. (1994) Standards main hurdle to new ATC technologies. Aviation Week & Space Technology , May 16. Norman, D.A. (1993). Things That Make Us Smart. New York: Addison Wesley. Norman, S., Billings, C.E., Nagel, D., Palmer, E., Wiener, E.L., & Woods, D.D. (1988). Aircraft Automation Philosophy: A Source Document. (NASA Technical Report). Moffett Field, California: Ames Research Center. Norman, D.A. and Bobrow, D.G. (1975). On data-limited and resource limited processes. Cognitive Psychology, 7(1), 44-64. Nygren, T.E.(1991). Psychometric properties of subjective workload measurement techniques: Implications for their use in the assessment of perceived mental workload. Human Factors , 33,17-33. Parasuraman, R., Molloy, R., & Singh, I.L. (1991). Performance consequences of automation-induced complacency. (Technical Report CSLA91-2). Washington, DC: Cognitive Science Laboratory, Catholic University of America. Parasuraman, R. (1987). Human Computer Monitoring. Human Factors, 29(6), 695-706. Paylor, A.(1993). Air Traffic Control: Today and Tomorrow. Shepperton, Surrey, England: Ian Allen Ltd. Plegrin, M. (1994). Electronic aids to controllers. In A. Benot (Ed.) On-line handling of air traffic. AGARD document AG-321. Brussels: NATO. Petre, E. (1994). Time based air traffic control in an extended terminal area. In A. Benot (Ed.) On-line handling of air traffic. AGARD document AG-321. Brussels: NATO. Pew, R.W. (1979). Secondary tasks and workload measurement. In N. Moray [Ed.], Mental Workload: Its Theory and Measurement. pp. 23-28. New York: Plenum Press.

DOC 99-70-02

Version 1.0 / August 1999

-139-

Recommended Literature

PHARE GHMI Project, Final Report

Phillipp, U., Reiche, D., & Kirchner, J.H. (1971). The use of subjective rating. Ergonomics, 14, 611-616. Raby, M. & Wickens, C.D. (1994). Strategic workload management and decision biases in aviation. International Journal of Aviation Psychology , 4(3), 211-240. Rasmussen, J. (1979). Reflections on the concept of operator workload. In N. Moray [Ed.], Mental Workload: Its Theory and Measurement. pp. 29-40. New York: Plenum Press. Reason, J. (1988). Cognitive under-specification: its varieties and consequences. In B.Baars (Ed.) The Psychology of Error: A Window on the Mind . New York: Plenum Press. Redding, R.E. (1992). Analysis of operational errors and workload in air traffic control. In Proceedings of the Human Factors Society 36th Annual Meeting , 1321-1325. Reiche, D., Kirchner, J.H. and Laurig, W. (1971). Evaluation of stress factors by analysis of radiotelecommunication in ATC. Ergonomics, 14, 603-609. Rieger, C.A. & Greenstein, J.S. (1983). The effects of dialogue-based task allocation on system performance in a computer aided air traffic control task. Behavior Research Methods & Instrumentation , 15(2), 208-212. Riley, V. (1994). A theory of operator reliance on automation. In M. Mouloua & R. Parasuraman (Eds .) Human Performance in Automated Systems: Recent Research and Trends (pp 8-14). Roscoe, A.H. (1978). Stress and workload in pilots. Aviation, Space and Environmental Medicine, 49(4), 630-636. Roth, E.M., Bennett, K.B. and Woods, D.D. (1987). Human interaction with an 'intelligent' machine. International Journal of Man Machine Studies , 27, 479-526. Rouse, W.B. (1988). Adaptive aiding for human/computer control. Human Factors , 30(4), 431-443. Rouse, W.B. (1994). Twenty years of adaptive aiding: origin of the concept and lessons learned. In M. Mouloua and R. Parasuraman [Eds .] Human Performance in Automated Systems: Current Research and Trends. Hillsdale, New Jersey: Erlbaum. Sanders, A.F. (1979). Some remarks on mental load. In N. Moray [Ed.], Mental Workload: Its Theory and Measurement. pp. 41-78. New York: Plenum Press. Sarter, N.R. & Woods, D.D. (1994). Decomposing automation: Autonomy, authority, observability and perceived animacy. In M. Mouloua and R. Parasuraman [Eds.] Human Performance in Automated Systems: Current Research and Trends. Hillsdale, New Jersey: Lawrence Erlbaum. Sarter, N.B. & Woods, D. (1991). Situation awareness: a critical but ill-defined phenomenon. International Journal of Aviation Psychology, 1(1), 45-57. Schneider, W. & Shiffrin, R.M. (1977). Controlled and automatic information processing. I: detection, search and attention. Bulletin of the Psychonomic Society , 18, 207-210.
-140Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Scott, B.C., Dargue, J. & Goka, T. (1991). Evaluation of Advanced Microwave Landing System Procedures in the New York Terminal Area. (DOT/FAA/ND-91/1). Washington, DC: US Department of Transportation, Federal Aviation Administration. Scott, W.B. (1994). CTAS tests confirm traffic flow benefits. Aviation Week and Space Technology. October 17, 1994. Selcon, SJ (1990). Decision support in the cockpit. Probably a good thing? In Proceedings of the Human Factors Society 34th Annual Meeting , pp 46-50, Santa Monica, California: Human Factors Society. Shaklee, H. and Fischhoff, B. (1982). Strategies of information search in causal analysis. Memory and Cognition , v10(6), 520-530. Sheridan, T.B. (1987). Supervisory control. In G. Salvendy (Ed.) Handbook of Human Factors . New York: Wiley. Sheridan, T.B. & Johannsen, G. (1976). Monitoring Behavior and Supervisory Control. New York: Plenum. Shortliffe, E.H. (1983). Medical consultation systems: Designing for doctors. In M.E. Sime and M.J. Coombs (eds.), Designing for Human-Computer Communication (pp. 209-238). New York: Academic Press. Silver, M.S. (1991). Systems that Support Decision Makers: Description and Analysis. New York: Wiley. Singh, I.L., Parasuraman, R., & Molloy, R. (1992). Monitoring Automation Failures: Relation to Automation-Induced Complacency, Personality, and Arousal. (Technical Report CSL-A-92-2). Washington, DC: Cognitive Science Laboratory, Catholic University of America. Slattery, R. & Green, S. (1994). Conflict-Free Trajectory Planning for Air Traffic Control Automation . NASA Technical memorandum 108790. Moffett Field, California: NASA Ames Research Center. Sperandio, J.C. (1971). Variations of operators'strategies and regulating effects on workload. Ergonomics , 14, 571577. Stager, P. (1991). The Canadian automated air traffic system (CAATS): an overview. In J. A. Wise et al. [Eds.], Automation and Systems Issues in Air Traffic Control. Berlin: Springer-Verlag. Stager, P. & Hameluck, D. (1990). Ergonomics in air traffic control. Ergonomics, 33(4), 493-499. Statsoft (1994). Users' Manual: Statistica for Microsoft Windows . Oklahoma City, Oklahoma: Statsoft, Inc. Stein, E.S. (1992). Air Traffic Control Visual Scanning . FAA Technical Report DOT/FAA/CT-TN92/16. US Department of Transportation. Stein, E.S. (1991). Air Traffic Controller Memory: A Field Study. DOT/FAA/CT-TN90/60. Atlantic City, New Jersey: FAA Technical Center.

DOC 99-70-02

Version 1.0 / August 1999

-141-

Recommended Literature

PHARE GHMI Project, Final Report

Stein, E.S. (1987). Where will all our air traffic controllers be in the year 2001? In Proceedings of the 4th Symposium on Aviation Psychology. pp 195-201. Columbus, Ohio: Ohio Sate University. Stein, E.S. (1985) Air Traffic Controller Workload: An Examination of Workload Probe . Report FAA/CTTN90/60). Atlantic City, New Jersey: FAA Technical Center. Stern, J.A. (1993). The eyes: reflector of attentional processes (synopsis by J. J. Kelly). In CSERIAC Gateway, 4 (4), 7-12. Stix, G. (1994). Aging Airways. Scientific American, May, pp 70-78. Thackray, R.I. (1991). Controller vigilance and monitoring performance. In Challenges in Aviation Human Factors: The National Plan . Washington, DC: American Institute of Aeronautics and Astronautics. Thackray, R.I. & Touchstone, R.M. (1989). Detection efficiency on an air traffic control monitoring task with and without computer aiding. Aviation, Space, and Environmental Medicine, August, 744-748. Thackray, R.I. & Touchstone, R.M. (1982). Performance of Air Traffic Control Specialists (ATC's) on a Laboratory RADAR Monitoring Task: An Exploratory Study of Complacency and a Comparison of ATCs and Non ATCs Performance. US Federal Aviation Administration report FAA-AM-82-1. Thackray, R.I. & Touchstone, R.M. (1989). Effects of High Visual Taskload on the Behaviors Involved in Complex Monitoring. Ergonomics, 32, 27-38. Tole, J.R., Stephens, A.T., Vivaudou, Eprath, A. & Young, L.R. (1983). Visual Scanning Behavior and Pilot Workload. NASA Contractor Report 3717. Hampton, Virginia: NASA Langley Research Center. Tversky, A. and Kahneman, D. (1974). Judgment under uncertainty: heuristics and biases. Science , 185, 1124-1131. Wagenaar, W.A. & Sagaria, S.D. (1975). Misperceptions of exponential growth. Perception and Psychophysics , 18(6), 416-422. Whitfield, D, Ball, RG, and Ord, G (1980). Some human factors aspects of computer-aiding concepts for air traffic controllers. Human Factors, 22(5), 569-580. Wickens, C.D.(1992). Engineering Psychology and Human Performance. 2nd ed. New York: Harper Collins. Wickens, C.D. (1980). The structure of processing resources. In R. Nickerson and R. Pew [Eds.] Attention and Performance VIII. Hillsdale, New Jersey: Erlbaum. Wickens, C.D. (1984). Processing resources in attention. In D. Davies & R. Parasuraman [Eds.] Varieties of Attention. New York: Academic Press. Wickens,C.D.,Hyman,F.,Dellinger,J.Taylor,H., & Meador,M. (1986). The Sternberg memory task as an index of pilot workload. Ergonomics, 29(11), 1371-1383. Wickens, C.D. & Kessel, C. (1980). Processing resource demands of failure detection in dynamic systems. Journal of Experimental Psychology: Human Performance and Perception . 6, 564-577.
-142Version 1.0/ August 1999 DOC 99-70-02

PHARE GHMI Project, Final Report

Recommended Literature

Wickens, C.D., Kramer, A.F., Vanasse, L. & Donchin, E. (1983). Performance of concurrent tasks: a psychophysiological analysis of the reciprocity of information processing resources. Science, 221, 1080-1082. Wickens, C.D., Stokes, A., Barnett, B., and Hyman, F. (1988). Stress and pilot judgment: an empirical study using MIDIS, a micro-computer-based simulation. In Proceedings of the Human Factor Society, 32nd Annual Meeting . Santa Monica, California: Human Factors Society. Wiener, E.L. (1980). Special issue preface. Human Factors, 22(5), 517-519. Wiener, E.L. & Curry, R.E. (1980). Flight deck automation: promises and problems. Ergonomics, 23, 995-1011. Wiener, E.L. (1987). Application of vigilance research: rare, medium, or well done? Human Factors, 29 (6), 725736. Wiener, E.L. (1985). Beyond the sterile cockpit. Human Factors , 27(1), 75-90. Wiener, E.L.(1988). Cockpit automation. In E.L. Wiener & D.C. Nagel [Eds .] Human Factors in Aviation . San Diego: Academic Press. Wierwille, W. (1979). Physiological measures of aircrew mental workload. Human Factors , 21, 575-594. Wierwille, W. & Connor, S. (1983). Evaluation of 20 workload measures using a psychomotor task in a moving base aircraft simulator. Human Factors , 25, 1-16. Will, R.P. (1991). True and false dependence on technology: Evaluation with an expert system. Computers in Human Behaviour, 7, 171-183. Yeh, Y. & Wickens, C.D. (1988). Dissociation of performance and subjective measures of workload. Human Factors, 30, 111120. Zeier, H. (1994). Workload and psychophysiological stress reactions in air traffic controllers. Ergonomics, 37(3), 525-539. Ziljstra, F.R.H & Doorn, L. van (1985). The Construction of a Scale to Measure Subjective Effort. Technical Report, Delft University of Technology, Department of Philosophy and Social Sciences.

DOC 99-70-02

Version 1.0 / August 1999

-143-

Recommended Literature

PHARE GHMI Project, Final Report

PHARE Publications PD/3 Synthesis report: DOC 99-70-01 Volume 1 of 4, CENA PD/3 Final report: DOC 99-70-01 Volume 2 of 4, EEC PD/3 Final Report: DOC 99-70-01 Volume 3 of 4, NLR PD/3 Final Report: DOC 99-70-01 Volume 4 of 4. PHARE GHMI project summary report: DOC 99-70-02 PHARE PATN project final report: DOC 99-70-03 PHARE CMS project final report: DOC 99-70-04 PHARE Validation project final report: DOC 99-70-05 NATS Trials Team: PD/1++ Trial Report DOC 98-70-16 EFMS Development Group: PD/3 Airborne Report DOC 98-70-19 PHARE Advanced Tools: Final Report DOC 98-70-18, Vol 1 of 10 NATS: PD/2+ Trial report DOC 97-70-17 PHARE final report: DOC-98-70-XX

-144-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.

ANNEXES
14.1. EXAMPLE OF GHMI SPECIFICATION FORMAT: THE ACTIVITY PREDICTOR DISPLAY.....147 14.1.1.
14.1.1.1. 14.1.1.2.

APD | Description ..............................................................................................147


APD | Figures ..........................................................................................................................................148 APD | Rules .............................................................................................................................................150

14.1.2. 14.1.3.
14.1.3.1. 14.1.3.2.

Primary APD | Window characteristics................................................................152 Primary APD | Window Content ..........................................................................153


Primary APD figures ...............................................................................................................................153 Figure comments.....................................................................................................................................153

14.1.4. 14.1.5.
14.1.5.1. 14.1.5.2.

Secondary APD | Window characteristics ...........................................................154 Secondary APD | Window Content .....................................................................155
Secondary APD figures ...........................................................................................................................155 Figures 4.7, 4.8 and 4.9 legends ..............................................................................................................156

14.1.6.
14.1.6.1. 14.1.6.2. 14.1.6.3. 14.1.6.4. 14.1.6.5. 14.1.6.6.

APD | Dialogues / Managing the APD display ......................................................157


F4101 (GF4)............................................................................................................................................157 F4102 (GF4)............................................................................................................................................158 F4103 Modifying the time scale into relative or absolute mode (GF4) ..................................................159 F4104 Adjusting the displayed time interval (GF4)................................................................................160 F4105 Modifying the transfer time limit of PROSIT (GF4)...................................................................162 F4106 Selecting the Maintain mode for the secondary APD (GF4).......................................................164

14.1.7.
14.1.7.1.

APD | Dialogues / Displaying / visualising filtered views .......................................165


F1401 (GF1)............................................................................................................................................165

14.1.8. 14.1.9.
14.1.9.1. 14.1.9.2. 14.1.9.3. 14.1.9.4. 14.1.9.5. 14.1.9.6. 14.1.9.7. 14.1.9.8. 14.1.9.9.

APD | Dialogues / Using look ahead displays ......................................................167 APD | Dialogues / Managing the PROSIT............................................................169
F420 (GF4)..............................................................................................................................................169 PROSIT states figures .............................................................................................................................169 F3102 Transferring manually a PROSIT to the TC APD (GF3)............................................................170 F4202 Removing manually a PROSIT from the APD (GF4).................................................................171 F4203 Cancelling a PROSIT removal proposed by the system (GF4)...................................................172 F4203 Accepting a PROSIT removal proposed by the system (GF4)....................................................173 F4204 Acknowledging a time limit alarm for one or more PROSIT (PRORES) (GF4) ........................174 F4205 Accepting a system proposal for an a/c to be added in an existing PROSIT (GF4)....................175 F4206 Refusing a system proposal for an a/c to be added in an existing PROSIT (GF4)......................176

14.1.8.1.1. .................................................................................................................................................................167

14.1.9.10. F4207 Accepting a system proposal for an a/c to be removed from an existing PROSIT (GF4)...........177 14.1.9.11. F4208 Refusing a system proposal for an a/c to be removed from an existing PROSIT (GF4).............178

14.1.10. APD | Dialogues / Managing the PRORES..........................................................179


14.1.10.1. F4301 (GF4)............................................................................................................................................179 14.1.10.2. PRORES states figures ............................................................................................................................180

14.1.11. APD | Dialogues / Managing the PREPLAB.........................................................181


14.1.11.1. F4401 (GF4)............................................................................................................................................181 14.1.11.2. F4402 (GF4)............................................................................................................................................183

DOC 99-70-02

Version 1.0 / August 1999

-145-

Annexes

PHARE GHMI Project, Final Report

14.1.11.3. F4403 (GF4) ........................................................................................................................................... 184 14.1.11.4. F4404 Acknowledging a time limit alarm for one or more acknowledged PREPLAB (GF4)............... 185 14.1.11.5. PREPLAB states figures ......................................................................................................................... 186

14.1.12. APD | Dialogues ............................................................................................... 187


14.1.12.1. F4501 (GF4) ........................................................................................................................................... 187 14.1.12.2. F4502 (GF4) ........................................................................................................................................... 188 14.1.12.3. F4503 (GF4) ........................................................................................................................................... 189 14.1.12.4. F4504 (GF4) ........................................................................................................................................... 191

14.1.13. APD | Dialogues / Being informed of problem events .......................................... 192


14.1.13.1. F4601 Being informed of a system proposal relevant to a PROSIT content modification (GF4).......... 192 14.1.13.2. F4602 Being informed of a system proposal relevant to a PROSIT removal (GF4).............................. 192 14.1.13.3. F4603 Being informed of PROSIT modification made by the system (GF4)........................................ 192 14.1.13.4. F4604 Visualising a PROSIT kept by the controller after a system removal proposition (GF4)........... 192 14.1.13.5. F4605 Being warned of a PROSIT time limit alert (GF4)...................................................................... 192

14.2. 14.2.1. 14.2.2. 14.2.3. 14.2.4.

THE INITIAL ROLE OF MAN DISCUSSION................................................................. 194 Introduction ...................................................................................................... 194 Human Factors Contributions to Air Traffic Control.............................................. 194 Research Programme ....................................................................................... 194 Conclusions ..................................................................................................... 197

-146-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.

EXAMPLE OF GHMI SPECIFICATION F ORMAT : THE ACTIVITY P REDICTOR DISPLAY APD WINDOW 14.1.1. APD | Description Phase : Mandatory

APD Window is used to provide special information related to air traffic. The window is organised on three levels: traffic problems for 3D and 4D a/c (PROSIT in the primary APD), problem resolutions in terms of new planned trajectory for 3D a/c (PRORES in the primary APD), traffic optimisation in nominal situation (a/c not involved in a traffic problem) for 3D a/c (PREPLAB in the secondary APD). All these information are presented in label forms that are linked in a dynamic way to a time axis. This specific view allows the controller to obtain a clear and chronological representation of the clearances to be given to the a/c.

DOC 99-70-02

Version 1.0 / August 1999

-147-

Annexes

PHARE GHMI Project, Final Report

14.1.1.1. APD | Figures

Phase :

Mandatory

Figure 44: Primary APD

-148-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

Figure 45: Secondary APD

DOC 99-70-02

Version 1.0 / August 1999

-149-

Annexes

PHARE GHMI Project, Final Report

14.1.1.2. APD | Rules

Phase :

Mandatory

The APD window cannot be iconified moved or re-sized. Primary APD and secondary APD cannot be displayed in the same time. A planning made on a 3D a/c which is not involved in a problem (PROSIT)4 is automatically displayed in the secondary APD in a PREPLAB form. The PREPLAB are displayed on both TC and PC position. The PRORES are displayed on both TC and PC position. The primary APD is displayed :

The primary APD is divided in two parts: the left hand part of the time axis is used to display the PROSIT / the right hand part is used to display the PRORES. The transfer line and the transfer symbol are displayed in the left hand part of the time axis of the PC primary APD only. They indicate to the PC the time limit after which the PROSIT will be automatically transferred to the TC. The secondary APD button (generic P) placed on the right hand side of the APD header and the arrow button placed on the right hand side of the APD bottom edge , allow the controller : to be informed of active preparations (specific colour coding), to get access to the secondary APD (only if it contains a PREPLAB at minimum). The generic P in the secondary APD button switches to the alarm coding if a PREPLAB is reaching the time limit boundary. In this case the secondary APD button is available. The PRORES are not displayed in the PC primary APD. The left hand part (interrogation mark side) is occupied by the PREPLAB which have not been acknowledged yet by the mean of the function F4401 or F4402. The right hand part (planning mark side) is occupied by the PREPLAB which have been acknowledged by mean of the function F4401 or F4402. Both PC and TC working position are provided with the secondary APD. The controller is advised of a new PRORES or PROSIT events by the mean of the PRORES Problem spy hole or the PROSIT Problem spy hole. The controller can perform the following actions through the Problem spy hole : displaying the STU mode if a new PROSIT is displayed (see F1401) / displaying a characterisation of the PRORES if a new PRORES is displayed.

The secondary APD is displayed :

4 It's a nominal situation opposed to a conflict situation.

-150-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

A new event always takes the previous event place in the Problem Spy Hole even if the controller has not performed any action on it. The previous rule is not available if the secondary APD is displayed using the Maintain Mode. In this case, a new event (PROSIT or PRORES) does not make disappear the Problem Spy Hole contents. It just induces the activation of the primary APD arrow. A new PROSIT or PRORES displayed in the Problem Spy Holes is removed only if an action is performed on it. The secondary APD is provided with a specific alarm field (PRORES alarm or PROSIT alarm) which are respectively activated when a PRORES or a PROSIT reaches the time limit boundary. The PROSIT (PRORES) Problem spy hole display is erased as soon as the PROSIT (PRORES) alarm field is activated (to avoid confusion between a new PROSIT (PRORES) and a PROSIT (PRORES) that has reached the time limit boundary). If a new PRORES / new PROSIT appears, a time-out is initiated which will make automatically the APD back to the primary APD after a 15 s duration. This time-out will be cancelled as soon as any action is performed in the Problem spy hole or in a PREPLAB. The controller (TC or PC) has the possibility to select the Maintain Mode of the secondary APD. This function allows the controller to keep longer the display of the secondary APD. In fact the time-out (5 s duration) still exists but it is activated only when a PRORES or a PROSIT reaches the time limit boundary (alarm zone). The primary APD button placed on the middle of the APD header and the arrow button placed on the right hand side of the APD bottom edge , allow the controller to access to the primary APD.

DOC 99-70-02

Version 1.0 / August 1999

-151-

Annexes

PHARE GHMI Project, Final Report

14.1.2. Primary APD | Window characteristics

Phase :

Mandatory

Window display attributes : Primary APD Frame Border Line style Line colour Square corners Header / Round Single, solid Black / yellow Square 1 Grey Generic P Black / yellow 14 pt Sans Serif Caps W Grey Fixed Right part of the screen 5 No Independent

Number of lines Background colour Header text Text colour Text fonts parameters

Background colour Default size Minimum size Maximum size Default position Priority on invocation Associated Toolbox Status (parent / child / independent) Window behavioural attributes Move Re-size Re-scale Iconify / De-iconify Close Open Scroll / Pan (page, incremental, manual)

No No No No System System Yes

-152-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.3. Primary APD | Window Content 14.1.3.1. Primary APD figures

Phase :

Mandatory

Figure 46: Primary APD header content

Figure 47: Primary APD bottom edge content

14.1.3.2. Figure comments 1 : Secondary APD button (including the generic P) 2 : PROSIT division button Action not implemented 3 : PROSIT creation button Action not implemented 4 : PROSIT unit button Action not implemented 5 : PROSIT / PRORES limit time alert icon 6 : PROSIT removal button (dustbin icon) 7 : Secondary APD arrow

Figure 48 PROSIT (the PROSIT shows a crossing problem between three a/c)

Figure 49: PRORES

DOC 99-70-02

Version 1.0 / August 1999

-153-

Annexes

PHARE GHMI Project, Final Report

14.1.4. Secondary APD | Window characteristics

Phase :

Mandatory

Window display attributes : Secondary APD Frame Border Line style Line colour Square corners Header / Single, solid Black Round Square 1 Grey APD New PRORES or PROSIT denomination PRORES or PROSIT alarm text

Number of lines Background colour Header text

Text colour

Black / red

Text fonts parameters 14 pt Sans Serif Caps Background colour Default size Minimum size Maximum size Default position Priority on invocation Associated Toolbox Status (parent / child / independent) Window behavioural attributes Move Re-size Re-scale Iconify / De-iconify Close Open Scroll / Pan (page, incremental, manual) No No No No System System Yes W Grey Fixed Right part of the screen 4 No Independent

-154-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.5. Secondary APD | Window Content 14.1.5.1. Secondary APD figures

Phase :

Mandatory

Figure 50: Secondary APD header content

Figure 51: Secondary APD top edge content

Figure 52: Secondary APD bottom edge content

DOC 99-70-02

Version 1.0 / August 1999

-155-

Annexes

PHARE GHMI Project, Final Report

14.1.5.2. Figures 4.7, 4.8 and 4.9 legends 1 : PROSIT time limit alert field 2 : PRORES time limit alert field 3 : PROSIT Problem spy hole 4 : PRORES Problem spy hole 5: Primary APD button 6 : Question mark zone 7 : Planning mark zone 8 : PREPLAB limit time alert icon 9 : Maintain Mode button 10 : Primary APD arrow

Figure 53: PREPLAB (Standard PREPLAB with several messages)

-156-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.6. APD | Dialogues / Managing the APD display

Phase :

Mandatory

14.1.6.1. F4101 (GF4)

Purpose Procedure Dialogue zone Constraints

To visualise the secondary APD to consult the current PREPLAB Manage APD / APD / secondary Secondary APD button, secondary APD arrow The primary APD is displayed There is an existing preparation at minimum

Particularities

The secondary APD display, activates a time-out in order to return automatically to the primary APD The effects take place only in the module in which the action has been initiated

P1
1.1 1

Actions Single click B1 on the secondary APD button. Single click B1 on the secondary APD arrow.

Effects The primary APD is removed. The secondary APD is displayed. Same effects

1.2 1

DOC 99-70-02

Version 1.0 / August 1999

-157-

Annexes

PHARE GHMI Project, Final Report

14.1.6.2. F4102 (GF4)

Purpose Procedure Dialogue zone Constraints Particularities

To return to the primary APD display Manage APD / APD / primary Primary APD button, primary APD arrow. The secondary APD is displayed The effects take place only in the module in which the action has been initiated. Actions Effects The secondary APD is removed. The primary APD is displayed. Same effects.

P1
1.1 1

Single click B1 on the primary APD button. Single click B1 on the primary APD arrow.

1.2 1

-158-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.6.3. F4103 Modifying the time scale into relative or absolute mode (GF4)

Purpose Procedure Dialogue zone Constraints

To change the scale of the time axis for both primary and secondary APD Manage APD / APD / scale mode Primary APD, inferior value The primary APD is displayed The function is available on the primary APD only

Particularities

The effects take place only in the module in which the action has been initiated The effects take place on both primary and secondary APD The values are displayed in the relative mode by default

P 1

Actions Single click B3 on the inferior value of the time axis.


m

Effects (the values are displayed in the relative mode). The values switch to the absolute mode. (the values are displayed in the absolute mode). The values switch to the relative mode.

Figure 54: Inferior value in the alarm zone

DOC 99-70-02

Version 1.0 / August 1999

-159-

Annexes

PHARE GHMI Project, Final Report

14.1.6.4. F4104 Adjusting the displayed time interval (GF4)

Purpose Procedure Dialogue zone Constraints Particularities

To increase or decrease the time scale in order to visualise more or less PROSIT, PRORES or PREPLAB Manage APD / APD / scale Primary APD, superior value, superior arrow, inferior arrow The secondary APD is displayed The effects take place only in the module in which the action has been initiated The effects take place on both primary and secondary APD If the superior value is equal to t0 (current time) plus 25 min, the superior arrow is not available If the superior value is equal to t0 (current time) plus 5 man, the inferior arrow is not available

P 1

Actions Place the cursor on the superior value field.

Effects The extended field with both superior and inferior arrows is displayed.

2 Single click B1 on the superior arrow. ...

The superior value (n) is increased to the n + 5 min value. The APD labels (PROSIT, PRORES, PREPLAB) are moved to their new position corresponding to the new selected scale.

or 2 ... Single click B1 on the inferior arrow. The superior value (n) is decreased to the n - 5 min value. The APD labels (PROSIT, PRORES, PREPLAB) are moved to their new position corresponding to the new selected scale. The APD labels that are placed on a time position which is superior to the new selected superior value are removed from the APD.

-160-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

Figure 55: Inferior and superior arrows of the superior value

DOC 99-70-02

Version 1.0 / August 1999

-161-

Annexes

PHARE GHMI Project, Final Report

14.1.6.5. F4105 Modifying the transfer time limit of PROSIT (GF4)

Purpose Procedure Dialogue zone Constraints

To modify the automatic transfer time limit of the PROSIT from the PC primary APD to the TC primary APD Manage APD / APD / transfer PC primary APD, transfer symbol The primary APD is displayed The transfer line cannot be moved inside the alarm zone

Particularities

The function is available on the PC primary APD only

P 1

Actions Press and drag B1 on the transfer symbol.

Effects The transfer line is moved to the bottom or the top of the APD following the motion of the cursor.

-162-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

1: PROSIT which has been manually transferred to the TC 2: PROSIT which has not been manually or automatically transferred to the TC. 3: Transfer symbol and transfer line 4: PROSIT which has not been manually or automatically transferred to the TC. 5: Alarm zone. Figure 56: Transfer symbol and transfer line

DOC 99-70-02

Version 1.0 / August 1999

-163-

Annexes

PHARE GHMI Project, Final Report

14.1.6.6. F4106 Selecting the Maintain mode for the secondary APD (GF4)

Purpose Procedure Dialogue zone Constraints Particularities

To select the mode that allows the controller to keep the secondary APD display for a longer time Manage APD / APD / Maintain Secondary APD, maintain mode button The secondary APD is displayed The effects take place only in the module in which the action has been initiated P : if activated the maintain mode is cancelled

P 1

Actions Single click B1 on the maintain mode button in the secondary APD.

Effects The time-out for secondary APD removal is initiated when a PRORES or a PROSIT reaches the time limit boundary (alarm zone).

Figure 57: Maintain mode button

-164-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.7. APD | Dialogues / Displaying / visualising filtered views

Phase :

Mandatory

14.1.7.1. F1401 (GF1)

Purpose Procedure Dialogue zone Constraints

To get access to a filtered view which is providing a clear traffic representation centred on the selected problem (STU) Additional information / filtered views / STU Secondary APD, Problem Spy Hole, PROSIT The primary APD is displayed In the STU mode only the conflicting aircraft TEDI are available for a new trajectory edition

Particularities

If displayed the STU is removed The effects take place only in the module in which the action has been initiated Actions Effects The standard RPVD switches to the STU mode. The STU menu is displayed on the bottom edge of the radar image. The PROSIT back colour switches to the STU mode colour coding. The STU is displayed : - The significant aircraft are displayed in the significant state coding. - The TEDI of the significant aircraft (only for them) are displayed with the red sections materialising the interacting zones. - If they exist, the contextual aircraft are displayed in their current Flight state coding. - The other aircraft are displayed using a grey coding.

15 Single Click B3 in the PROSIT (in the primary APD or in the Problem Spy Hole).

5 The underlining means that it is the last action of the procedure

DOC 99-70-02

Version 1.0 / August 1999

-165-

Annexes

PHARE GHMI Project, Final Report

The removal of the STU mode can be also invoked by the following action:

Single Click B1 in the CANCEL item6 of the STU menu.

The PROSIT back colour returns to the standard colour coding. The STU is removed : - The TEDI are removed. - All the aircraft are displayed using their Flight state coding. The standard RPVD is displayed.

6 This item is to be defined

-166-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.8. APD | Dialogues / Using look ahead displays 14.1.8.1.1.

Phase :

Mandatory

Purpose Procedure Dialogue zone Constraints

To visualise the traffic situation centred on the problem subset in a extrapolated time Additional info / ahead / PROSIT Primary APD, PROSIT The primary APD is displayed The STU mode is activated

Particularities

The effects take place only in the module in which the action has been initiated Actions Effects The pointing cursor switches to an open hand cursor. The Look ahead PROSIT is displayed. The look ahead vector is displayed from the PROSIT clock to the cursor and follows the moving cursor. A mirror callsign label is displayed on each trajectory of the significant aircraft. These mirror labels are moved along their current trajectory accordingly to the extrapolated time (a/c label stay at a/c current radar position).

P 1

Press and drag B1 on the PROSIT clock.

The removal of the look ahead mode is invoked by the following action:

Release B1.

The open hand cursor returns to the pointing cursor. The look ahead vector is removed from the PROSIT. The mirror labels disappear.

DOC 99-70-02

Version 1.0 / August 1999

-167-

Annexes

PHARE GHMI Project, Final Report

Figure 58: PROSIT in the Look ahead mode

-168-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.9. APD | Dialogues / Managing the PROSIT 14.1.9.1. F420 (GF4) Function not implemented 14.1.9.2. PROSIT states figures

Phase :

Mandatory

9
1 : Standard PROSIT
2 : PROSIT to be transferred 3 : PROSIT to be removed 4 : Extended PROSIT to be removed 5 and 6 : PROSIT to be changed 7 : Extended PROSIT to be changed 8 : Time limit alert on PROSIT 9 : Look ahead PROSIT with look ahead vector

Figure 59: PROSIT symbolical coding states

DOC 99-70-02

Version 1.0 / August 1999

-169-

Annexes

PHARE GHMI Project, Final Report

14.1.9.3. F3102 Transferring manually a PROSIT to the TC APD (GF3)

Purpose Procedure Dialogue zone Constraints

To transfer a PROSIT to the PC before the automatic transfer limit Communicate / Transfer Primary APD, PROSIT, transfer symbol The PC primary APD is displayed The function is not available for the TC

Particularities

The transfer is made automatically 6 min before the problem occurrence Actions Effects The PROSIT is displayed in the TC primary APD. The transfer symbol is removed from the PROSIT in the PC primary APD.

P 1

Symbol click B1 on the transfer symbol of the PROSIT.

Figure 60: PROSIT with the transfer symbol

-170-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.9.4. F4202 Removing manually a PROSIT from the APD (GF4)

Purpose Procedure Dialogue zone Constraints Particularities

To remove a PROSIT from the APD without waiting for the system proposal Manage APD / PROSIT / remove 1 Primary APD, PROSIT, dustbin icon The primary APD is displayed The effects take place only in the module in which the action has been initiated The function is not available for the PRORES A removed PROSIT cannot be displayed again in the APD Several PROSIT can be selected at a single time in order to be removed simultaneously

Actions

Effects The PROSIT switches to the selected colour coding.

1. Single click B1 on the PROSIT. ..

Single click B1 on the dustbin icon.

The PROSIT is removed from the APD.

DOC 99-70-02

Version 1.0 / August 1999

-171-

Annexes

PHARE GHMI Project, Final Report

14.1.9.5. F4203 Cancelling a PROSIT removal proposed by the system (GF4)

Purpose Procedure Dialogue zone Constraints

To keep a PROSIT in the APD even if the system considers that there is no longer problem Manage APD / PROSIT / keep Primary APD, PROSIT, dustbin zone, NO field The primary APD is displayed A dustbin zone is displayed closed to the PROSIT

Particularities

The effects take place in both PC and TC modules. A kept PROSIT is no longer carried-out by the system and will not induce any alarm when it will reach the alarm zone (it will simply disappear as soon as it reaches the current time)

Actions

Effects The YES and NO fields are displayed above the dustbin zone.

1. Place the cursor on the dustbin zone of .. the PROSIT.

Single click B1 on the NO field of the PROSIT.

The YES and NO fields are removed. The dustbin zone is removed. The PROSIT switches into the Kept PROSIT coding.

-172-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.9.6. F4203 Accepting a PROSIT removal proposed by the system (GF4)

Purpose Procedure Dialogue zone Constraints

To remove a PROSIT from the APD according to the system proposal Manage APD / PROSIT / remove 2 Primary APD, PROSIT, dustbin zone, NO field The primary APD is displayed A dustbin zone is displayed closed to the PROSIT

Particularities P

The effects take place in both PC and TC modules. Actions Effects The YES and NO fields are displayed above the dustbin zone.

1. Place the cursor on the dustbin zone of .. the PROSIT.

Single click B1 on the YES field of the PROSIT.

The PROSIT is removed from the APD.

Figure 61: PROSIT with the dustbin zone and the YES/NO fields

DOC 99-70-02

Version 1.0 / August 1999

-173-

Annexes

PHARE GHMI Project, Final Report

14.1.9.7. F4204 Acknowledging a time limit alarm for one or more PROSIT (PRORES) (GF4)

Purpose Procedure Dialogue zone Constraints

To remove all the HMI effects induced by the PROSIT (PRORES) time limit alert Manage APD / PROSIT / alert Primary APD, PROSIT (PRORES), PROSIT / PRORES time limit alert icon The primary APD is displayed One or more PROSIT (PRORES) are displayed using the alarm coding

Particularities

The effects take place on both modules (PC and TC) Several PROSIT (PRORES) can be selected at a single time in order to be acknowledged simultaneously The function is available for the TC only

Actions

Effects The PROSIT switches to the selected colour coding.

1. Single click B1 on the PROSIT .. (PRORES).

Single click B1 on the PROSIT / PRORES time limit alert icon.

(PROSIT context) The F4605 effects are cancelled

(PRORES context) The F1204 effects are cancelled)

-174-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.9.8. F4205 Accepting a system proposal for an a/c to be added in an existing PROSIT (GF4)

Purpose Procedure Dialogue zone Constraints

To allow the system to add a supplementary a/c in a PROSIT that has been already consulted by the controller Manage APD / PROSIT / system proposal 1 Primary APD, PROSIT, YES field The primary APD is displayed The callsign of the a/c to be added and the + question mark zone are displayed closed to the PROSIT

Particularities P 1

The effects take place on both modules (PC and TC) Actions Effects The YES and NO fields are displayed above the proposed callsign and in place of the question mark.

Place the cursor on the question mark zone or on the proposed callsign.

Single click B1 on the YES field.

The YES and NO fields and the proposed callsign are removed from the PROSIT. The a/c is known by the system as a new a/c involved in the problem.

Figure 62: PROSIT with the question mark and the YES/NO fields

DOC 99-70-02

Version 1.0 / August 1999

-175-

Annexes

PHARE GHMI Project, Final Report

14.1.9.9. F4206 Refusing a system proposal for an a/c to be added in an existing PROSIT (GF4)

Purpose Procedure Dialogue zone Constraints

To keep the system from adding a supplementary a/c in a PROSIT that has been already consulted by the controller Manage APD / PROSIT / system proposal 2 Primary APD, PROSIT, NO field The primary APD is displayed The callsign of the a/c to be added and the + question mark zone are displayed closed to the PROSIT

Particularities P 1

The effects take place on both modules (PC and TC) Actions Effects The YES and NO fields are displayed above the proposed callsign and in place of the question mark.

Place the cursor on the question mark zone or on the proposed callsign.

Single click B1 on the NO field.

The YES and NO fields and the proposed callsign are removed from the PROSIT. The proposed a/c is not involved in the problem.

-176-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.9.10.F4207 Accepting a system proposal for an a/c to be removed from an existing PROSIT (GF4)

Purpose Procedure Dialogue zone Constraints

To allow the system to removed an a/c from a PROSIT that has been already consulted by the controller Manage APD / PROSIT / system proposal 3 Primary APD, PROSIT, YES field The primary APD is displayed The callsign of the a/c to be removed and the - question mark zone are displayed closed to the PROSIT

Particularities P 1

The effects take place on both modules (PC and TC) Actions Effects The YES and NO fields are displayed above the proposed callsign and in place of the question mark.

Place the cursor on the question mark zone or on the proposed callsign.

Single click B1 on the YES field.

The YES and NO fields and the proposed callsign are removed from the PROSIT. The a/c is no longer known by the system as an a/c involved in the problem.

DOC 99-70-02

Version 1.0 / August 1999

-177-

Annexes

PHARE GHMI Project, Final Report

14.1.9.11.F4208 Refusing a system proposal for an a/c to be removed from an existing PROSIT (GF4)

Purpose Procedure Dialogue zone Constraints

To keep the system from removing an a/c from a PROSIT that has been already consulted by the controller Manage APD / PROSIT / system proposal 4 Primary APD, PROSIT, NO field The primary APD is displayed The callsign of the a/c to be removed and the - question mark zone are displayed closed to the PROSIT

Particularities P 1

The effects take place on both modules (PC and TC) Actions Effects The YES and NO fields are displayed above the proposed callsign and in place of the question mark.

Place the cursor on the question mark zone or on the proposed callsign.

Single click B1 on the NO field.

The YES and NO fields and the proposed callsign are removed from the PROSIT. The a/c is still known by the system as an a/c involved in the problem.

-178-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.10.APD | Dialogues / Managing the PRORES

Phase :

Mandatory

14.1.10.1.F4301 (GF4)

Purpose Procedure Dialogue zone Constraints

The TC gives instructions by VHF and updates in real time the part of the STRAJ associated to each given instruction Manage APD / PRORES / VAL PRORES, message field Only for 3D a/c The primary APD is displayed The function is not available for the PC

Particularities P1 1

The effects take place on both modules (PC and TC) Actions Effects

Single Click B1 on the message field The instruction is displayed on the radar label (line 3 or 4) within the corresponding of the PRORES.

field (ahdg, asp, arc or CFL7 ).

The instruction message is removed from the PRORES.


m

(others instruction messages are still to be validated in the PRORES) The PRORES is moved on the APD vertical time axis in order to be placed at the new time corresponding to the next instruction message to be validated. (it is either the single or the last message of the PRORES list). The PRORES is removed from the primary APD.

The CLEARANCE marker is placed on the new trajectory at the end of the part that materialises the validated instruction message.

7 See [1] chapter 5.2.4 (the different forms of the radar label)

DOC 99-70-02

Version 1.0 / August 1999

-179-

Annexes

PHARE GHMI Project, Final Report

14.1.10.2. PRORES states figures 1 : Standard PRORES with a single message 2 : Standard PRORES with several messages 3 : Extended PRORES 4 : Time limit alert on PRORES

Figure 63: PRORES symbolical coding states

-180-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.11.APD | Dialogues / Managing the PREPLAB 14.1.11.1.F4401 (GF4)

Phase :

Mandatory

Purpose Procedure

The TC acknowledge the trajectory preparation in order to register it as the new STRAJ P1 : via the PREPLAB P2 : via the radar label

Dialogue zone

P1 : secondary APD, PREPLAB, YES field P2 : radar label, P symbol, YES field

Constraints

The secondary APD is displayed The trajectory preparation has not been already acknowledged via the function F4402 procedure. P1 : The extended PREPLAB is displayed P2 : The prepared trajectory is displayed The function is not available for the PC

Particularities P1 1

The effects take place on both modules (PC and TC). Actions Effects The trajectory preparation is registered as the new STRAJ and is displayed in flashing green coding (for 3 s) on the RPVD in place of the current trajectory. The P symbol is removed from the radar label in both modules (PC and TC). The planning mark is displayed in the label and in the SIL (if it exists) in place of the P symbol. The PREPLAB is moved after a 3 s delay to the planning mark side of the secondary APD.

Single Click B1 on the YES field of the PREPLAB.

DOC 99-70-02

Version 1.0 / August 1999

-181-

Annexes

PHARE GHMI Project, Final Report

P2 1

Actions
Single Click B1 on the OK field close to the beginning of the trajectory in preparation.

Effects Same effects.

Figure 64: OK field and prepared trajectory

-182-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.11.2. F4402 (GF4)

Purpose Procedure Dialogue zone Constraints

The TC gives instructions by VHF and updates in real time the segment of the STRAJ associated to each given instruction Manage APD / PREPLAB / VAL PREPLAB, message field Only for 3D a/c The secondary APD is displayed The function is not available for the PC

Particularities P1 1 Actions

The effects take place on both modules (PC and TC) Effects
m

Single Click B1 on the message field of the PREPLAB.

(it is the first message and the function F4401 has not been performed on the PREPLAB). The trajectory preparation is registered as the new STRAJ and is displayed in flashing green coding (for 3 s) on the RPVD in place of the current trajectory. The P symbol is removed from the radar label in both modules (PC and TC). The planning mark is displayed in the label and in the SIL (if it exists) in place of the P symbol. The PREPLAB is moved after a 3 s delay to the planning mark side of the secondary APD. The preparation message is validated as a tactical solution. The instruction is displayed on the radar label (line 3 or 4) in the corresponding field (ahdg, asp, arc or CFL). The preparation message is removed from the PREPLAB. (others preparation messages are still to be validated in the PREPLAB) The PREPLAB is moved on the APD vertical time axis to be placed at the new time corresponding to the next preparation message to be validated. (it is the single or the last message of the PREPLAB) The PREPLAB is removed from the secondary APD. The CLEARANCE marker is placed on the new trajectory at the end of the part materialising the validated message.

DOC 99-70-02

Version 1.0 / August 1999

-183-

Annexes

PHARE GHMI Project, Final Report

14.1.11.3.F4403 (GF4)

Purpose Procedure

The TC refuses the trajectory preparation P1 : via the PREPLAB P2 : via the radar label

Dialogue zone

P1 : secondary APD, PREPLAB, NO field P2 : radar label, P symbol, NO field

Constraints

The secondary APD is displayed The trajectory preparation has not been acknowledged via the function F4402 procedure P1 : The extended PREPLAB is displayed P2 : The prepared trajectory is displayed

Particularities

The effects take place on both modules (PC and TC) The action can be made by both PC and TC

P1 1

Actions
Single Click B1 on the NO field of the PREPLAB.

Effects The trajectory preparation is cancelled. The P symbol is removed from the radar label. The P symbol is removed from the SIL (if it exists). The PREPLAB is removed from the secondary APD after a dt (3 s).
m

P2 1 Actions
Single Click B1 on the NO field of the trajectory preparation.

(it is the single current preparation) The generic P symbol is switched back to the greyed-out P symbol in the secondary APD button. Effects

The trajectory preparation is cancelled. The P symbol is removed from the radar label in both modules (PC and TC). The P symbol is removed from the SIL (if it exists). The PREPLAB is removed from the secondary APD after a dt (3 s).

(it is the single current preparation) The generic P symbol is switched back to the greyed-out P symbol in the secondary APD button.
DOC 99-70-02

-184-

Version 1.0/ August 1999

PHARE GHMI Project, Final Report

Annexes

14.1.11.4.F4404 Acknowledging a time limit alarm for one or more acknowledged PREPLAB (GF4)

Purpose Procedure Dialogue zone Constraints

To remove all the HMI effects induced by the PREPLAB time limit alert Manage APD / PREPLAB / alert Secondary APD, PREPLAB, PREPLAB time limit alert icon The secondary APD is displayed One or more PREPLAB are displayed using the alarm coding

Particularities

The effects take place on both modules (PC and TC) Several PREPLAB can be selected at a single time in order to be acknowledged simultaneously The function is available for the TC only

Actions

Effects The PREPLAB switches to the selected colour coding.

1. Single click B1 on the PREPLAB. ..

Single click B1 on the PREPLAB time limit alert icon.

The F1201 effects are removed. The PREPLAB and the time limit alert icon in the secondary APD return to the standard coding.

DOC 99-70-02

Version 1.0 / August 1999

-185-

Annexes

PHARE GHMI Project, Final Report

14.1.11.5.PREPLAB states figures

1: PREPLAB with single message placed in the question mark side 2: Extended PREPLAB (YES / NO fields) with single message in the question mark side 3: PREPLAB with several messages placed in the question mark side 4: Extended PREPLAB (YES / NO fields and secondary message) with several messages in the question mark side 5: PREPLAB that has overshot the time limit in the question mark side (it is removed) 6: Extended PREPLAB with several messages in the planning mark side 7: PREPLAB with single message placed in the planning mark side 8: PREPLAB with several messages placed in the planning mark side 9: PREPLAB which has overshot the time limit in the question mark side (alert coding)

Figure 66: PREPLAB symbolical coding states

-186-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.12.APD | Dialogues 14.1.12.1.F4501 (GF4)

Phase :

Mandatory

Purpose Procedure Dialogue zone Constraints Particularities

To visualise on the RPVD the new planned trajectory associated to the PRORES Manage APD / associated info / CHAR Primary APD, Problem Spy Hole, PRORES, message field The primary APD is displayed P2 : If displayed the PRORES characterisation is removed The effects take place in the module in which the action has been initiated

P1
1.1 1

Actions Press and HOLD B3 within the message field.

Effects The callsigns of the significant aircraft corresponding to the PROSIT are displayed temporarily using the warning coding. The previous trajectory of the a/c is temporarily displayed on the RPVD.

P2
1.2 1

Actions Single Click B3 within the message field.

Effects The callsigns of the significant aircraft corresponding to the PROSIT are displayed using the warning coding. The previous trajectory of the a/c is displayed on the RPVD.

P1: The removal of the PRORES characterisation is invoked by the following actions:

P1
1.1 1

Actions Release B3.

Effects The callsigns of the significant aircraft corresponding to the PROSIT switch to the flight state coding. The previous trajectory of the a/c is removed from the RPVD.

DOC 99-70-02

Version 1.0 / August 1999

-187-

Annexes

PHARE GHMI Project, Final Report

14.1.12.2.F4502 (GF4)

Purpose Procedure Dialogue zone Constraints

To visualise the tactical solutions messages in a PRORES which are not displayed at a first level8 Manage APD / associated info / PRORES Primary APD, PRORES, arrow field The primary APD is displayed The PRORES presents an arrow field

Particularities

the hidden messages are not activable The effects take place in the module in which the action has been initiated

P1 1

Actions Place the cursor on the arrow field.

Effects The extended PRORES is displayed after a dt delay (0.5 s).

The removal of the extended PRORES is invoked by the following action :

P1 1

Actions Move the cursor out of the PRORES field.

Effects The extended PRORES is removed.

8 A first level message is a message that is shown in the standard PRORES (see figure 4.20.)

-188-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.12.3.F4503 (GF4)

Purpose Procedure

To visualise the trajectory preparation on the RPVD Manage APD / associated info / Traj PREP P1 : for a fixed mode P2 : for a quick look mode

Dialogue zone Constraints Particularities

Radar label, SIL, P symbol, PREPLAB, message field The secondary APD is displayed P1 : if displayed the preparation trajectory is removed The effects take place in the module in which the action has been initiated

P1
1.2 1

Actions Single Click B3 on the P symbol displayed within the radar label or within the SIL if it exists. Single Click B3 in the message field of the PREPLAB.

Effects The preparation trajectory is displayed in addition with the current STRAJ in the RPVD using preparation colour coding and using dashed line. Same effects.

1.2 1

P2
1.1 1

Actions Press and Hold B3 on the P symbol displayed in the radar label or in the SIL if it exists. Press and Hold B3 in the message field of the PREPLAB.

Effects The preparation trajectory is temporarily displayed in addition with the current STRAJ in the RPVD using preparation colour coding and using dashed lines. Same effects.

1.1 1

The removal of the preparation trajectory is invoked by the following actions:

P2
1.1 1

Actions Release B3.

Effects The preparation trajectory of the a/c is removed from the RPVD.

DOC 99-70-02

Version 1.0 / August 1999

-189-

Annexes

PHARE GHMI Project, Final Report

Figure 67: P symbol within the SIL (a) and on the radar label (b)

-190-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

14.1.12.4.F4504 (GF4)

Purpose Procedure Dialogue zone Constraints

To visualise the preparation messages in a PREPLAB which are not displayed at a first level Manage APD / associated info / PROSIT Primary APD, PREPLAB, arrow / question mark field or arrow field (allocated fields) The secondary APD is displayed (there are several messages) The PREPLAB presents an arrow / question mark field (there is one message only) The PREPLAB presents question mark field

Particularities

The hidden messages are not activable The effects take place in the module in which the action has been initiated

P1 1

Actions Place the cursor in the allocated field.


m

Effects (there are several messages and the prepared trajectory has not been acknowledged yet) The extended PREPLAB is displayed after a dt delay (0.5 s) showing the preparation messages to be sent after the first one and the YES / NO fields. (there are several messages and the prepared trajectory has been acknowledged before) The extended PREPLAB is displayed after a dt delay (0.5 s) showing the preparation messages to be sent after the first one. (there is a single message and the prepared trajectory has not been acknowledged yet) The extended PREPLAB is displayed after a dt delay (0.5 s) presenting the YES / NO fields.

The removal of the extended PREPLAB is invoked by the following action :

P1 1

Actions Move the cursor out of the PREPLAB field.

Effects The extended PREPLAB is removed.

DOC 99-70-02

Version 1.0 / August 1999

-191-

Annexes

PHARE GHMI Project, Final Report

14.1.13.APD | Dialogues / Being informed of problem events

Phase :

Mandatory

14.1.13.1. F4601 Being informed of a system proposal relevant to a PROSIT content modification (GF4) See figure 4.16. / 5-6 14.1.13.2. F4602 Being informed of a system proposal relevant to a PROSIT removal (GF4) See figure 4.16. / 3 14.1.13.3.F4603 Being informed of PROSIT modification made by the system (GF4) See Summary of supplementary objects codings 14.1.13.4. F4604 Visualising a PROSIT kept by the controller after a system removal proposition (GF4) See Summary of supplementary objects codings 14.1.13.5.F4605 Being warned of a PROSIT time limit alert (GF4)

Purpose Procedure Coding zones Constraints Particularities P1 1 Actions

The controller is alerted that a PROSIT has reached alarm zone in the primary APD APD / problem events / PROSIT Radar label, limit time icon in the primary APD, PROSIT alarm field in the secondary APD None The alarm effects are displayed on both modules (PC and TC) Effects The significant a/c labels switch to the warning coding in the RPVD.
m

The PROSIT has reached the alarm zone boundary in the primary APD.

(the primary APD is displayed) The PROSIT and the time limit alarm icon switch to the alarm coding. (the secondary APD is displayed). The PROSIT specific alarm field is activated until the primary APD is back to the prior display (manually or automatically).
m

(the maintain mode is activated) The primary APD is automatically displayed 5 s after the beginning of the alarm.

-192-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

Figure 68: Alarm (or Warning) coding on the radar label

DOC 99-70-02

Version 1.0 / August 1999

-193-

PHARE GHMI Project, Final Report

Annexes

14.2.

T HE INITIAL ROLE OF MAN DISCUSSION 14.2.1. Introduction The following section will present the major conclusions and recommendations of the role of man group. This ad hoc group of subject matter experts started the process of trying to integrate Human Factors into programmes that were essentially technology driven when they were conceived. This material formed the starting point for defining the overall GHMI project. 14.2.2. Human Factors Contributions to Air Traffic Control The need to apply human factors principles to large human machine systems such as air traffic control systems has been accepted for many years. The nature of the contributions of human factors as a discipline to air traffic control has gradually evolved with changing air traffic control requirements, advancing technology, and acknowledgement of the breadth of human factors contributions that are required. These have been defined in a series of studies (Hopkin 1970, 1982, 1988) on human factors, and also in a series of authoritative reviews of air traffic control and of its associated research and development which include human factors contributions along with contributions from many other disciplines (Benoit 1975, 1980, 1983, 1986). Although the need for human factors contributions to air traffic i.e. control systems was recognised, the methods of applying human factors were in retrospect somewhat arbitrary, being influenced not only by needs and resources but also by funding and the location of expertise. Recently the roles of human factors in relation to air traffic control have become more clearly defined and more formalised. The United States National Plan for Aviation Human Factors with its comprehensive compilation of research issues to be addressed and the MANPRINT program as an example of a formalised mechanism for applying human factors to large systems have helped to formalise its roles and contributions. Recent ICAO interest represented by the publication later this year (ICAO, 1993) of a human factors digest on air traffic control demonstrates that the application of human factors in this context is becoming acknowledged world-wide. It is in this context that the PHARE 'Role of Man' project should be placed, as a further initiative to organise and specify the application of human factors to an evolving programme, in this case the Programme of Harmonised Air Traffic Management Research in EUROCONTROL (PHARE). 14.2.3. Research Programme Perhaps the most essential point is that the human factor contributions to PHARE should be planned as a programme and implemented as a programme. An implication is that the human factors problems associated with the PHARE programme would seriously overstretch the resources and capabilities of any one nation or research establishment, but that collectively the research establishments contributing to the EUROCONTROL programme could make the required human factors contributions to the PHARE programme effectively, provided that all the contributions made are planned as a whole, and are constituents of a unified programme of work. The separate parts of the work must have sufficient in common with each other to enable their findings to be interpreted not merely in isolation but in relation to the programme as a whole and to other findings being obtained elsewhere within PHARE,

-194-

Version 1.0 / August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

The focus of this report is on the role of man (ROM), that is, on what the future roles of controllers should be in the future air traffic management system to which the PHARE programme is addressed. This implies that the roles must be suitable for the air traffic control objectives and matched with them, that they must be roles which the trained and experienced controllers can fulfil efficiently and safely, that controllers find those roles acceptable and satisfying since an intention must be to retain the experienced controller workforce, and that the roles do not in any way harm those who fulfil them. ]t is essential to make full use of those attributes in which humans excel, to make full use of those attributes where machines and computers excel, to use human and machine to circumvent and compensate for any weaknesses or deficiencies in the other, and to match human and machine to achieve the maximum efficiency and safety. Wherever possible, existing evidence should be applied within PHARE provided that it is demonstrably valid for air traffic management, but it is inevitable, particularly in an era of new air traffic management requirements and major technological advances, that in some respects existing evidence will be inadequate and research may therefore have to be specially commissioned to obtain the evidence to provide the required human factors guidelines.

THE NEED FOR ITERATION

The application of human factors advice and knowledge in relation to PHARE must to some extent be an iterative process. As systems become more precisely defined, the corresponding human factors recommendations can become more detailed, immediately practical and also more specific to the particular system as it is evolving. The form of human factors advice and recommendations that can be given on matters of planning and policy is different from the much more detailed level applied at the final system design and evaluation stages. ]t is important to provide human factors advice iteratively throughout the system evolution so that best human factors solutions are not precluded by decisions taken at an earlier stage of system evolution for other reasons, without realisation of their full human factors implications, particularly in the form of options which they exclude. A great deal of information is available about most modern aircraft in flight, from which a small selection is made which is appropriate and sufficient to represent those aircraft to the controller for the purposes of controlling them as air traffic. As technological advances provide more and better information about each aircraft, and as the ways of controlling aircraft as traffic themselves evolve (for example from tactical intervention with single aircraft towards the planning of traffic flows) the question must be reviewed from time to time of whether the means of representing aircraft as traffic which have served so well in the past will continue to be the most appropriate means to represent air traffic in future, or whether novel, and perhaps highly innovate, alternative means should be tried. The combination of data in plan view with alphanumeric data in tabular form has always presented problems of cognitive compatibility, and any solutions which circumvent this problem, perhaps by adopting neither approach, have a major advantage if they have avoided the need for cognitive integration of radically different kinds of information.

DOC 99-70-02

Version 1.0 / August 1999

-195-

Annexes HUMAN MACHINE RELATIONSHIPS

PHARE GHMI Project, Final Report

When computer assistance was first introduced into air traffic control, there were few feasible human machine relationships. Essentially the human al first had to adapt to the machine because the machine was not adaptable. There then followed a period as technology advanced when the number and nature of roles which could be considered for human or machine allocation expanded rapidly, purely as a result of technological developments. Only if a machine could fulfil a function, does it make sense to ask the question whether a human or machine should fulfil it. In this era the human was therefore in a sense competing with the machine for functions and must lose, because the competition could occur only where machines appropriate for the functions could be developed and those machines would become relatively more efficient as a result of their further development. The next phase concerned the total replacement of the human by the machine. This can be effective for basic tasks such as data gathering, storage, collation and presentation. There was an attempt to make the machine and human complementary, but this relationship proved quite difficult to design and implement when it was first proposed over twenty years ago and it was superseded by the notion of human and machine as mutually symbiotic, although this would seem to preclude the notion of manual reversion in the event of machine failure which remained a human requirement. More recently, machine developments have meant that the human may take over from a failed machine, be adapted to by the machine, or be interchangeable with the machine. It becomes conceivable to allow human or machine to fulfil particular functions in parallel, by duplication or optionally one with the other, in the sense that the allocation of a function to either human or machine need not imply that the other cannot or must never fulfil that function. In an era where future machines may be intelligent, adaptable, innovative, or flexible it seems clear that some future roles must envisage human and machine being mutually adaptable to each other, but the principles of how this is best achieved when both human and machine possess such attributes as intelligence, flexibility, adaptability and a capacity to innovate are not yet clear. Technological advances have offered the further options that there can be fluid and not necessarily predetermined or fixed relationships between human and machine, and such a principle if correct applied may be a means to ensure safety, to smooth workload, and to allow Human and machine to be mutually supportive. An ultimate role of machines may be to take over in the event of human incapacitation. The above brief description of different kinds of human machine relationships reveals that there are a very large number of kinds of relationships to choose from because technical advances have continued to offer further options, yet all the original options are also still available. Existing knowledge about the various options varies greatly because some are long standing and some are recent. It is very unlikely that a single kind of relationship would be optimum for all human functions in relation to machines within the PHARE programme and therefore the strengths and weaknesses of the alternatives need to be addressed to achieve the best balance between human and machine.

-196-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

Some issues clearly have to be addressed. It is vital that the human jobs seem sensible to those who perform them. It is essential that some form of feedback and learning is incorporated so that controllers can benefit and improve from experience. It is highly desirable to ensure that al] that is proposed within the PHARE programme is acceptable and engenders favourable attitudes towards it since these may be a prerequisite for their successful operational introduction ultimately. It may be that the issue of human intentionally needs to be addressed so that when a problem or emergency arises the human controller can inform the machine of his or her intentions and enlist machine help in achieving human objectives. lt is also important to consider the factor of observability. Many of the roles traditionally fulfilled in air traffic control have been fully observable by others in the workspace. lt is not nearly as easy to observe and understand what is happening when most of the actions consist of data entry. A further factor concerns legal responsibilities. lt is essential that the PHARE programme as a whole must ensure that where controllers have clearly defined legal responsibilities the equipment, facilities and information they are provided with and the procedures and instructions they have to follow and the tasks which they must do will] collectively allow them to fulfil those responsibilities which are legally theirs.

14.2.4. Conclusions
HUMAN FACTORS OBJECTIVES

Human factors should be applied throughout the PHARE programme. The objectives are to the success of PHARE and the safety and efficiency of its final products, to optimise the roles within it; to ensure that human and machine are correctly matched and mutually supportive; to confirm that the PHARE programme itself and the air traffic control systems it will lead to or influence will not harm those who work within them; and to provide satisfying, productive and valued work for future generations of air traffic controllers. This implies that it is envisaged that there will continue to be significant full time for controllers within the medium term and in the longer term also. Much of the work in this report addresses human factors problems in the medium term within PHARE, but this work should be supplemented by some longer term studies on topics such as the evaluation of the potential benefits of further dynamic task switching and sharing as these options become more technically feasible and refined.
ITERATIONS

An iterative approach is envisioned in the application of human factors, with the level of detail at the human factors issues are addressed remaining in step with the level of detail of designs and specifications as they progressively develop during system evolution. The broad task categories are expected to evolve towards more specific tasks as plans, specifications and designs become more detailed. The earliest attempts to apply human factors as a discipline were to systems designs. Human in the PHARE programme is returning to its roots, being concerned with plans, policies, and designs rather than with trying to cure the incurable retrospectively. The human as an information processing system should be utilised in the light of recent cognitive advances and understanding of human information processing much of is reviewed and discussed in this report. Emphasis on design should also restore the emphasis on objectives and reasons for them, with more work to ascertain that objectives have met and less to examine the minutiae of what is actually being done to achieve those

DOC 99-70-02

Version 1.0 / August 1999

-197-

Annexes

PHARE GHMI Project, Final Report

which may not always be very important. The stages in designing a human centred interface described in this report should normally be followed, or at least relatively similar processes to those stages.
SINGLE UNIFYING PROGRAMME

The human factors contributions within PHARE need to be a single coherent programme which contains means to unify the parts of that programme with each other since those parts may be conducted with different resources, establishments and staffs. Methods, measures, constructs, 'Experimental designs, traffic scenarios, specifications, equipment, forms of data, forms of computer assistance, display conventions, types and formats of input devices, knowledge, procedures, instructions and forms of training are all tools which properly applied, can contribute towards unifying the programme. At least several of these means of unification should be adopted throughout the programme so that the findings from each part of the programme can be interpreted in relation to the whole, and do not take the form of a series of unconnected items. lndividuals or groups will need to be tasked to ensure sufficient commonality beforehand so that the results of different studies will be interpretable in relation to each other, whatever the findings of each study may be. Although the primary emphasis must be on the roles of controllers it is advisable that any roles for supervisors or assistants to those controllers should be planned in conjunction with the controller roles and not as add-ons when the controller roles have already been defined and when many of the options for efficient supervision or assistance may have been excluded.
WORK ELSEWHERE

There are opportunities to learn extensively from work elsewhere from theories, from air traffic control experience, from applications of formalised human factors processes, and from other attempts to devise a programme of human factors research in air traffic control such as that within the United States National Plan for Aviation Human Factors. This work may not always produce evidence or procedures which are directly applicable to PHARE but often it will. Maximum use should be made of this work elsewhere including co-ordination with any identified parallel studies in other countries, to share results and common experience. In addition to profiting from work in the past or currently being done elsewhere, it is also possible to build on the many established human factors principles and these are listed in an appendix. They should be treated as guidelines, which are generally valid, since each depends on extensive evidence. These principles should be followed wherever possible with steps to confirm and verify their applicability to air traffic control.

-198-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

TEACHABILITY

Given that there will be jobs for human controllers in air traffic control for a considerable time, it is essential that these jobs are sensible, make use of the relevant training, human knowledge and experience, and are acceptable to controllers themselves and to others. Wherever a new task or function or role for controllers is proposed, not only is it essential to ensure that humans can perform their assigned functions safely and efficiently, but it is also essential to ensure that the human functions are teachable and that appropriate training can be devised. In a programme of studies and evaluations it is important to recognise any aspects of controllers' tasks which were difficult to teach or which controllers did not perform as planned in order to make suitable changes in the future training and to confirm the teachability of the new functions. Evidence on current differences between expert and novice controllers should be applied to assess teachability and to ascertain level of progress during learning.
PROBLEM-DRIVEN APPROACH

A problem driven rather than a technology driven approach is advocated as the best means to deploy the limited human factors resources available most efficiently. lt is envisioned that best progress would be made by planning the evolutionary development of future human roles from current ones. Final objectives and intended end states should also be defined, using a top down approach so that these two approaches can serve as mutual cheeks and means of identifying any residual problems if there are disparities between them. The need to evolve from current systems is a practical necessity, but so is the need to define potential end states, so that when they have been achieved, this can be recognised. It is considered that in the earlier stages the technological innovations and developments will serve primarily as support tools and the automation provided within PHARE would remain essentially human centred. Ultimately, it will be necessary to try and evolve principles for matching human and machine when both have attributes such as innovation, intelligence, adaptability, and flexibility. New options are becoming technically available and the means of using them within PHARE must be addressed, although their full technical refinement whereby they can safely be applied within air traffic control seems likely to be in the longer rather than the shorter term. It is intended with PHARE largely to retain existing team structures and associated team roles. This should mean that most of the mechanisms and functions currently fulfilled by teams remain significant unimpaired or unaffected within PHARE, but it is prudent to check and confirm this rather than to assume it. The major developments in team training in other contexts should be evaluated for PHARE. The legal implications of the role of the human in PHARE have to be addressed, because the reasons for certain facilities or for the form which they take are not primarily technical or human factors reasons but rather legal ones, to enable the controller to exercise responsibilities for which he or she is responsible. This criterion should often be applied during the iterative process to ensure that no controller is ever in the position of having the legal responsibility, but no means to exercise it or insufficient knowledge to understand it.

DOC 99-70-02

Version 1.0 / August 1999

-199-

Annexes HUMAN ERROR

PHARE GHMI Project, Final Report

Where there are humans there is the potential for human error. A guiding principle must be to design the workspace from the outset to minimise or prevent the commonest errors and to ensure that any that remain cannot be concealed but must be revealed. This has to be linked to policies on how fault tolerant the system is, and on how far the ramifications of any human error or any machine fault extend. Often the human controller does not need to know the nature of a fault and its causes, but does need to know how far its effects extend, and particularly which facilities remain unaffected by it and usable as normal.
TASK ANALYSIS

Some form of task analysis, including human information processing functions, is necessary for learning and understanding the role of the human controller in relation to the PHARE programme. This includes decisions on the controllers' picture, on the controllers' level of experience and on the controllers responsibilities, although task analysis as a technique has its limitations and has to be supplemented by other methods. Taxonomy of variables affecting controllers and tasks provides a useful starting point but such taxonomy of functions should never be treated as fully comprehensive. Often factors are not fully treated such as, navigational sources, the forms of equipment and computer assistance provided, the degree of openness and observability of the workspace, and the desirable level of situation awareness as relevant factors differentiating controllers and their tasks. Nevertheless it provides a basis for a classification of many of the main variables, and such a basis is needed for defining jobs, tasks, and functions. The chapter also provides a useful review and initial taxonomy of some relevant cognitive factors in relation to air traffic control tasks, and also warns of some incipient problems, such as increased monitoring, reduced familiarity, new possible error sources, and decreased mutual collaboration between controllers. The consequences of decisions about the specification of the humanmachine interface in terms of the openness and observability of the workspace to others should be cheeked as this determines the feasibility of certain forms of supervision and independent verification.

HUMAN-MACHINE INTERFACE

The design of the human machine interface has a crucial influence on determining the role of the human controller within PHARE. Only the information displayed or made accessible to the controller is available for use by the controller. Other information, no matter how relevant it may be, can have no influence on human tasks. It is therefore vital, to define carefully all the information that may be needed and to make adequate provision for it to be available. Similarly the only actions which the controller can initiate are those for which some provision has been made in the specification of the input devices provided. The controller may devise an intelligent and innovative solution to a problem, but if the means to implement it are not provided then that solution couldnt be adopted. The importance of the human machine interface specification is not only to ensure that all the known tasks are performed safely and efficiently, but also as the means to implement any policies there may be about intelligence innovation and flexibility. The specification of the workspaces and the human machine interface in particular should also encourage considerable commonality across equipment and practices.

-200-

Version 1.0/ August 1999

DOC 99-70-02

PHARE GHMI Project, Final Report

Annexes

Human factors criteria, in addition to those of technical reliability, suitability, cost efficiency, and expected benefits, should be applied to assess proposed forms of computer assistance for controllers, and to match them with human capabilities and limitations. These criteria must emphasise safety and performance, but should also include effects on teams, on observability, on human roles, and on human attitudes, including acceptability. Work may be needed to establish how the extensive existing evidence on the formation and effects of attitudes could best be utilised within the PHARE programme. As changes in the envisaged human roles become more apparent, these should be related to the current selection criteria for air traffic controllers, to check whether new required controller attributes should be added to the selection procedure and whether some existing selection tests should be discarded as no longer appropriate. Air traffic i.e. control uses a limited selection of the information available about aircraft in order to represent and control them as traffic. As the roles of human controllers evolve, it may be that the traditional forms of representing traffic may no longer be the most appropriate for the new forms of air traffic control that will be required. More extensive computer assistance will tend to dissociate the human controller further from the aircraft under his or her control, but it is an assumption and not a proven fact that this greater dissociation must be inherent less safe, and evidence may be needed to discover whether or not such an assumption can be justified. The human factors considerations on the role of man within PHARE envisage that real-time simulation must probably remain the primary investigative tool, but whenever possible it should be preceded by supplementary laboratory studies on simpler simulations and should also be followed by operational or field studies to confirm and validate the real-time simulations. Simulations cannot provide valid answers to every human factors question, and their inherent limitations have to be acknowledged and circumvented. All research on human factors issues within PHARE should be genuine, in the sense that the outcome is not known in advance and that the findings of the research if valid will be implemented, even if they are not what was predicted or hoped for. In human factors work, the whole is always more than the sum of the parts, and this will apply to the PHARE programme and to the separate parts of it. The need to be able to interpret these parts in relation to each other is thus an indispensable feature of the PHARE programme as a whole.

DOC 99-70-02

Version 1.0 / August 1999

-201-

You might also like