PHARE Ground Human Machine Interface (GHMI) project ...€¦ · PHARE programme and was responsible for the delivery of the Human Machine Interface (HMI) specifications. An international

DOC 99-70-02

PHARE Ground Human MachineInterface (GHMI) project:

Summary report

PHARE/NLR/GHMI-7/FR/1.0

Prepared by: P.G.A.M. Jorna NLR,D. Pavet CENA,M. van Blanken NLR,I. Pichancourt EEC

Date: August 99

EUROCONTROL96 rue de la Fusée

B-1130 BRUXELLES

Copyright Statement PHARE GHMI project, Final Report

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

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 thatdue acknowledgement of authorship is made by quoting the copyright statementbelow. The copyright and the foregoing condition on publication and reproductionshall 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 thePHARE Participants shall provide no express or implied warranty of any kind andshall accept no liability whatsoever for or in connection with the use of the informationcontained in the document.

* The PHARE Participants are:

- the EUROCONTROL Agency;

- the CENA (Centre d'études de la navigation aérienne);

- the STNA (Service technique de la navigation aérienne);

- the NLR (Nationaal Lucht- en Ruimtevaartlaboratorium);

- the RLD (Rijksluchtvaartdienst);

- the LVNL (Luchtverkeersleiding Nederland);

- the DLR (Deutsches Zentrum für 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 AirNavigation (EUROCONTROL); the CENA (Centre d'études de la navigationaérienne); the STNA (Service technique de la navigation aérienne); the NLR(Nationaal Lucht- en Ruimtevaartlaboratorium); the RLD (Rijksluchtvaartdienst); theLVNL (Luchtverkeersleiding Nederland); the DLR (Deutsches Zentrum für Luft- undRaumfahrt); the DFS (Deutsche Flugsicherung GmbH); the UK CAA (Civil AviationAuthority); the NATS (National Air Traffic Services) and the DERA (DefenceEvaluation and Research Agency).

All rights reserved.

PHARE GHMI project, Final Report Revision History

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

REVISION HISTORY

Date Revision Number Reason for revision

Jan 99 0.2 Initial complete draft

May 99 0.3 First comments from Document Review Groupincorporated

July 99 0.4 Further comments incorporated

August 99 1.0 Publication version

Document Approval PHARE GHMI project, Final Report

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

DOCUMENT APPROVAL

NAME SIGNATURE DATE

AUTHOR 1 P. Jorna (NLR) Sep 99

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 ProgrammeManager

H. Schröter(EUROCONTROL)

Sep 99

PHARE GHMI project, Final Report Executive Summary

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

EXECUTIVE SUMMARY

The GHMI project was aimed at developing a next generation of controller workingpositions to be used in future Air Traffic Management concepts. It was part of thePHARE programme and was responsible for the delivery of the Human MachineInterface (HMI) specifications. An international team that combined Human Factorsspecialists with engineers and operational experts performed the work. The resultingspecifications were based on multi-disciplinary expertise, extensive user interactionand practical support provided by means of exploratory Human Factors studiesconsidering overall automation philosophies, possible applications of software toolslike conflict detection, problem solvers etc.

The report will provide a historic overview of the project, as it developed over a periodapproaching almost ten years of work in the area. First of all, the results of an earliertask force on the expected ‘Role of man’ in future systems will be discussed. Thatdiscussion provided some important starting points for the GHMI project definition andits overall design goals. Subsequently, the project structure and managementintegration in the overall programme is explained. After presenting this backgroundmaterial, the results of some exploratory experiments are discussed. The use ofsoftware assistance to the controller was found to reduce the controller’s workloadobjectively, provided that the design of the ‘tools’ was effective enough to be alsousable under high traffic load conditions. Controllers tended to revert to old controllingstrategies or habits under high pressure and as a consequence sometime drop thetools. Training issues are discussed in the context of HMI familiarisation and furtherwork is recommended. Subjective and objective workload measurements tend todissociate, stressing the importance of objective evaluations as compared to personalopinion and the use of a more representative participant population.

Four main GHMI specifications were produced, one for each segment of flight i.e. theDeparture, En-route, Approach & Arrivals and the Multi-sector controller workingpositions. The detailed design specifications are not a part of this report as they aretoo 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 highlyexperimental but in the end they were generally well received and accepted. The useof graphical direct object manipulation and other features was initially met with somesceptics, but after gaining experience with the system, appreciation increased. Therole of various training facilities has been very instrumental in achieving such positiveacceptance. Many of the achievements have been incorporated in other programs likeEATCHIP and also the FAA has expressed interest.

As early as PHARE Demonstration 1, it was learnt that transferring existingconventions onto new designs was not effective. Novel features of the environmentthat were initially deemed as potentially unacceptable, when brought to life in realHMI, were accepted by controllers and with further experience their potential could beexploited.

The GHMI project recommends that advantage be taken of the PHARE technologiesand simulation platforms, which provide a unique opportunity to investigate possiblefuture configurations in terms of controller performance and safety. Exploratorystudies should also be made into integration of airborne separation assurance and thePHARE ground based separation concept based on D trajectories.

PHARE GHMI project, Final Report


This page left intentionally blank

PHARE GHMI project, Final Report List of Contents


LIST OF CONTENTS1. INTRODUCTION..................................................................................................... 11

2. THE GOALS OF THE GHMI PROJECT ................................................................... 13

2.1. THE HUMAN FACTOR............................................................................................. 13

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

2.3. STATE OF THE ART ............................................................................................... 17

2.4. DESIGN REQUIREMENTS ........................................................................................ 18

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

3.1. GHMI PROJECT STRUCTURE ................................................................................... 20

3.2. THE DESIGN PROCESS........................................................................................... 21

3.3. THE DESIGN TEAM ................................................................................................ 21

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

4.1. AUTOMATION PHILOSOPHIES .................................................................................. 23

4.2. THE TOOLS APPROACH.......................................................................................... 24

4.3. TASK AND SKILL ANALYSIS .................................................................................... 25

4.3.1. Task-logic diagrams ....................................................................................... 27

5. RESULTS............................................................................................................... 34

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

5.1.1. Input devices.................................................................................................. 345.1.2. Gesture recognition ........................................................................................ 385.1.3. Controller data link interface............................................................................ 38

5.1.4. Conflict detection and resolution tools.............................................................. 435.1.5. Arrival sequence tool ...................................................................................... 455.1.6. The Highly Interactive Problem Solver (HIPS).................................................. 47

5.2. THE GHMI TRAINING APPROACH.............................................................................. 51

5.2.1. Initial training approach................................................................................... 515.2.2. The CBT HMI familiarisation approach............................................................. 53

5.2.3. Training benefits............................................................................................. 565.3. THE GHMI DESIGNS............................................................................................. 57

5.3.1. The en-route GHMI (PD-1).............................................................................. 57

5.3.2. The approach GHMI (PD-2) ............................................................................ 635.3.3. The multi-sector Gate to Gate GHMI’s (PD-3)................................................... 73

6. THE CENA/PD3 GROUND HUMAN-MACHINE INTERFACE.................................... 80

6.1. EXAMPLES OF GHMI IMPLEMENTATIONS ................................................................. 81

6.1.1. The main screen............................................................................................. 836.1.2. The ancillary screen........................................................................................ 83

6.2. THE TMA DEPARTURE CWP................................................................................. 84

6.2.1. The main screen............................................................................................. 85

List of Contents PHARE GHMI project, Final Report


6.2.2. The ancillary screen........................................................................................ 856.3. INTEGRATION OF PHARE ADVANCED TOOLS........................................................... 86

6.3.1. Trajectory Predictor (TP)................................................................................. 866.3.2. Conflict Probe (CP)......................................................................................... 866.3.3. Flight Path Monitor (FPM) ............................................................................... 87

6.3.4. Negotiation Manager (NM) .............................................................................. 876.3.5. Problem Solver (PS)....................................................................................... 876.3.6. Departure Manager (DM) ................................................................................ 87

6.3.7. Co-operative tools (CT)................................................................................... 886.4. MAIN LESSONS LEARNT......................................................................................... 88

6.5. GHMI DISPLAYS AND INTERACTIONS ...................................................................... 89

6.5.1. TEPS/TST...................................................................................................... 896.5.2. MIW/MOW ..................................................................................................... 916.5.3. CRD (used only in the Baseline environment)................................................... 91

6.5.4. SIL................................................................................................................. 916.5.5. Advisories labels in the APD............................................................................ 926.5.6. Departure Manager......................................................................................... 92

7. THE NLR/ PD3 GROUND HUMAN-MACHINE INTERFACE...................................... 94

7.1. AIRSPACE AND OVERVIEW GHMI’S......................................................................... 94

7.2. EXAMPLES OF GHMI IMPLEMENTATIONS ................................................................. 95

7.2.1. ACC and TMA working positions...................................................................... 957.2.2. Arrival Manager Display (BaseAMD) ................................................................ 977.2.3. Vertical View Display (VVD) ............................................................................ 98

7.3. ROLES AND WORKING PROCEDURES ....................................................................... 99

7.3.1. Aircraft states ............................................................................................... 1007.3.2. En-route Planning Controller.......................................................................... 101

7.3.3. En-route Tactical Controller ........................................................................... 1087.4. INTEGRATION OF PHARE ADVANCED TOOLS......................................................... 111

7.4.1. Trajectory Predictor (TP)............................................................................... 111

7.4.2. Flight Path Monitor (FPM) ............................................................................. 1117.4.3. Conflict Probe (CP)....................................................................................... 1117.4.4. Arrival Manager (AM).................................................................................... 112

7.4.5. Negotiation Manager (NM) ............................................................................ 1127.5. THE AIRCRAFT HMI ............................................................................................ 113

7.6. MAIN LESSONS LEARNT....................................................................................... 115

7.7. GHMI DISPLAYS AND INTERACTIONS .................................................................... 115

7.7.1. Trajectory display (Dynamic Flight Leg Display).............................................. 1157.7.2. TST............................................................................................................. 116

7.7.3. Labels.......................................................................................................... 1167.7.4. CRD ............................................................................................................ 1167.7.5. HIPS............................................................................................................ 116

8. DISCUSSION........................................................................................................ 117

8.1. THE DESIGN PROCESS ......................................................................................... 117

8.1.1. The specification format ................................................................................ 117

PHARE GHMI project, Final Report List of Contents


8.1.2. The evaluation process..................................................................................1188.1.3. Controller acceptance....................................................................................118

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

8.2.1. Changing roles in teams ................................................................................1198.2.2. Responses to high traffic loads.......................................................................119

8.2.3. Situational awareness....................................................................................119

9. CONCLUSIONS ....................................................................................................121

9.1. THE DESIGN GOALS.............................................................................................121

9.2. CONTROLLER SKILLS...........................................................................................121

10. RECOMMENDATIONS ..........................................................................................123

10.1. FUTURE USE OF RE-CONFIGURABLE TOOLS AND GHMI.............................................123

10.2. ATM DEVELOPMENTS: AIRBORNE OPPORTUNITIES ..................................................123

10.3. AND THE FUTURE….............................................................................................123

11. ACKNOWLEDGEMENTS.......................................................................................125

12. GLOSSARY, LIST OF ACRONYMS .......................................................................127

13. RECOMMENDED LITERATURE............................................................................131

14. ANNEXES .............................................................................................................145

14.1. EXAMPLE OF GHMI SPECIFICATION FORMAT: THE ACTIVITY PREDICTOR DISPLAY .......147

14.1.1. APD | Description ......................................................................................14714.1.2. Primary APD | Window characteristics ........................................................152

14.1.3. Primary APD | Window Content ..................................................................15314.1.4. Secondary APD | Window characteristics....................................................15414.1.5. Secondary APD | Window Content..............................................................155

14.1.6. APD | Dialogues / Managing the APD display ..............................................15714.1.7. APD | Dialogues / Displaying / visualising filtered views................................16514.1.8. APD | Dialogues / Using look ahead displays...............................................167

14.1.9. APD | Dialogues / Managing the PROSIT....................................................16914.1.10. APD | Dialogues / Managing the PRORES ..................................................17914.1.11. APD | Dialogues / Managing the PREPLAB.................................................181

14.1.12. APD | Dialogues ........................................................................................18714.1.13. APD | Dialogues / Being informed of problem events ...................................192

14.2. THE INITIAL ‘ROLE OF MAN’ DISCUSSION .................................................................194

14.2.1. Introduction ...............................................................................................19414.2.2. Human Factors Contributions to Air Traffic Control.......................................19414.2.3. Research Programme ................................................................................194

14.2.4. Conclusions ..............................................................................................197




PHARE GHMI project, Final Report Introduction


1. INTRODUCTION

The GHMI project was aimed at developing a next generation of controller workingpositions. It was part of the PHARE programme and was essentially tasked with thedelivery of the Human Machine Interface or HMI specifications.

This report will provide a historic overview of the projects as it developed over a periodapproaching almost ten years of work in the area. It started with a discussion on therole of man in future systems and the resulting overall design goals. Subsequently, theintegration in the overall programme is explained and the adopted project structure.Issues basic to the work are discussed in some detail, such as Automationphilosophies and the use of particular design methods. After presenting thisbackground material, the results of exploratory experiments are discussed. Theseformed the basis for the actual design work pursued later in the project. The resultingdesigns are presented and their results reviewed. The report concludes with lessonslearnt and recommendations for future work.

The detailed design specifications are not a part of this report as they are too lengthyfor inclusion. The reader is referred to the applicable PHARE documents.




PHARE GHMI project, Final Report The Goals of the GHMI Project


2. THE GOALS OF THE GHMI PROJECT

2.1. THE HUMAN FACTOR

At the conception of the GHMI project, it could not be taken for granted that the so-called Human Factor would have to play a significant role in the future Air TrafficManagement systems. The importance of the so-called Human Factor in determiningthe effectiveness and efficiency of ATC was more and more realised by users of thepresent ATC systems, but different ideas existed on the way forward. Technologyseemed to have leaped forward in such a way, that some considered full automaticATC as the way ahead, or even the best final solution for the Human Factor problem.Many international conferences, as an example the Advanced Study Institutessupported by NATO, discussed this issue and came to the conclusion that even fullautomatic 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 issuesrelated 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 inAir Traffic Control (1991)’ and Verification and Validation of Complex Systems: HumanFactors Issues (1993)’.

A first discussion within PHARE was therefore directed towards deciding on the ‘Roleof Man’ in future ATM. This work was performed by an ad-hoc group of subject matterexperts. They concluded that the application of Human Factors was indeedconsidered important but that funding and resources were not always in place. The USnational Plan for Aviation Human Factors was an example of a commendable initiativethat was widely discussed and supported but in the end not heavily supported byactual funding. One reason perhaps was that Human Factors used to be studiedparticularly by the academia while the development of new systems is stronglydominated by industry. National research establishments play an important role inbridging possible gaps and the PHARE programme represented a wonderfulopportunity to break such borders, as it comprised a team of research establishmentsand ATC providers.

2.1.1. The starting points

The role of man was therefore soon recognised and the following recommendationswere formulated as a starting point by the role of man group:

• HUMAN FACTORS OBJECTIVES

Human factors should be applied throughout the PHARE programme. Theobjectives are to realise the success of PHARE, the safety and efficiency of itsfinal products, to optimise the roles within it; to ensure that human and machineare correctly matched and mutually supportive; to confirm that the PHARE airtraffic control systems will not harm those who work within them and to providesatisfying, productive and valued work for future generations of air trafficcontrollers. This implies that it is envisaged that there will continue to besignificant full time work for controllers within the medium term and in the longerterm also.

The Goals of the GHMI Project PHARE GHMI project, Final Report


• ITERATIONS

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

• SINGLE UNIFYING PROGRAMME

The human factors contributions within PHARE need to be a single coherentprogramme which contains means to unify the parts of that programme with eachother 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 computerassistance, 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 meansof unification should be adopted throughout the programme so that the findingsfrom each part of the programme can be interpreted in relation to the whole, anddo 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 aconsiderable time, it is essential that these jobs are sensible, make use of therelevant training, human knowledge and experience, and are acceptable tocontrollers themselves and to others. Wherever a new task or function or role forcontrollers is proposed, not only is it essential to ensure that humans can performtheir assigned functions safely and efficiently, but it is also essential to ensure thatthe human functions are teachable and that appropriate training can be devised.In a programme of studies and evaluations it is important to recognise anyaspects of controllers' tasks which were difficult to teach or which controllers didnot perform as planned in order to make suitable changes in the future trainingand to confirm the teachability of the new functions.

• PROBLEM-DRIVEN APPROACH

A ‘problem driven’ rather than a ‘technology driven’ approach is advocated as thebest means to deploy the limited human factors resources available mostefficiently. The need to evolve from current systems is a practical necessity, but sois 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 technologicalinnovations and developments will primarily serve as support tools and theautomation provided within PHARE would remain essentially human centred.Ultimately, it will be necessary to try and evolve principles for matching human andmachine when both have attributes such as innovation, intelligence, adaptability,and flexibility. New options are becoming technically available in the (far) future. Itis intended within PHARE to largely retain the existing team structures andassociated team roles. This should mean that most of the mechanisms andfunctions currently fulfilled by teams remain significant unimpaired or unaffectedwithin PHARE, but it is prudent to check and confirm this rather than to assume it.



• 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 notprimarily technical or human factors reasons but rather legal ones. To enable thecontroller to actually exercise the responsibilities for which he or she isresponsible. This criterion should often be applied during the iterative process toensure 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 principlemust be to design the workspace from the outset to minimise or prevent thecommonest errors and to ensure that any that remain cannot be concealed butmust be revealed. This ‘error trapping’ has to be linked to policies on how faulttolerant the system is, and on how far the ramifications of any human error or anymachine fault extend. Often the human controller does not need to know thenature 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, isnecessary for learning and understanding the role of the human controller inrelation to the PHARE programme. This includes decisions on the controllers'picture, on the controllers' level of experience and on the controller’sresponsibilities. Task analysis as a technique has its limitations and has to besupplemented by other methods.

• HUMAN-MACHINE INTERFACE

The design of the human machine interface has a crucial influence on determiningthe role of the human controller within PHARE. Only the information displayed ormade accessible to the controller is available for use by the controller. Otherinformation, no matter how relevant it may be, can have no influence on humantasks. It is therefore vital, to define carefully all the information that may beneeded and to make adequate provision for it to be available. Similarly the onlyactions which the controller can initiate are those for which some provision hasbeen made in the specification of the input devices provided. The controller maydevise an intelligent and innovative solution to a problem, but if the means toimplement it are not provided, then that solution couldn’t be adopted. Thespecification of the workspaces and the human machine interface in particularshould also encourage considerable commonality across equipment andpractices.

Human factors criteria, in addition to those of technical reliability, suitability, costefficiency, and expected benefits, should be applied to assess proposed forms ofcomputer assistance for controllers, and to match them with human capabilitiesand limitations. These criteria must emphasise safety and performance, but shouldalso include effects on teams, on observability, on human roles, and on humanattitudes, including acceptability.



As ATM and the roles of human controllers evolve, it may be that the traditionalforms of representing traffic may no longer be the most appropriate for the newforms of air traffic control that will be required. More extensive computerassistance will tend to dissociate the human controller further from the aircraftunder his or her control. It is an assumption and not a proven fact that suchgreater dissociation must be inherent less safe, and evidence may be needed todiscover whether or not such an assumption can be justified.

• SIMULATION

The human factors considerations on the role of man within PHARE envisage thatreal-time simulation must probably remain the primary investigative tool.Whenever possible, it should be preceded by supplementary laboratory studieson simpler simulations and should also be followed by operational or field studiesto confirm and validate the real-time simulations. Simulations cannot provide validanswers to every human factor question, and their inherent limitations have to beacknowledged and circumvented. All research on human factors issues withinPHARE should be genuine, in the sense that the outcome is not known inadvance and that the findings of the research if valid will be implemented, even ifthey are not what was predicted or hoped for. In human factors work, the whole isalways more than the sum of the parts, and this will apply to the PHAREprogramme and to the separate parts of it. The need to be able to interpret theseparts in relation to each other is thus an indispensable feature of the PHAREprogramme as a whole.

A more detailed discussion document of the Role of Man group is provided as anAnnex to this report.

2.2. THE FUTURE USERS

The users for the PHARE systems are essentially people who will live somewhere inthe future. The exact time scope is depending on both the successes of the PHAREprogramme and the time needed for the development of industrial products, i.e. thereal operational system with its finalised controller working positions.

Based on this future perspective (formulated around 1990) the following factors had tobe taken into consideration:

- The so-called ‘baby boom’ after the Second World War has led to a certain agedistribution in the eighties and nineties. This age distribution resulted in a relativehigh availability of persons who could apply for a job in ATC. Therefore selectionratios could be high and attrition during training could be counteracted by using asurplus strategy. Essentially, there was room for selecting and training the ‘rightstuff’.

- The after baby boom effect however, will result in a lower total availability ofpersons and a different age distribution. Both younger and older persons couldbecome or stay involved in the future ATC system.

- Given a lower availability of persons, compensation has to be sought and severalstrategies could apply. One is to reduce the number of persons needed by strivingfor full automation or high levels of automation. Another one is to keep persons inservice longer than today. In any case, the requirements for a reduction ofworkload and increased trainability seem immense.



- Another issue is that the future users will become more computer literate, implyingthat the experimental systems developed now, could be totally obsolete when thenext generation of computer systems is quite more advanced. Those couldroutinely include speech and intent recognition, dynamic scheduling of tasks andresponsibilities etc. Therefore, design goals should not be too modest in order togain acceptance of the present generation of controllers.

- In order to gain acceptance, additional work is anticipated in order to train presentday 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 wellas older controllers who (had to) stay in service. Therefore, the design was planned toaim more at the average person in an attempt to reduce possible future needs forextremely experienced controllers or special ‘aces’.

2.3. STATE OF THE ART

This section will briefly describe some of the major starting points for the GHMIproject. At the time of its initiation, the state of the art was essentially represented bythe results of projects like the EUROCONTROL project ODID III, introducing andexploring the concepts of windowing and the full use of colour. Other partners inEurope 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 ofelectronic flight strips or not, was a hot one. In the USA, a Centre Tracon AutomationSystem was under development aiming at integrating trajectory negotiation etc. Thatprogram was highly technology orientated and did not include a strong HMI part. Fullautomation, 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, aspursued by the so-called ARC 2000 programme. It was also the end of the advent ofCommercial off the shelf solutions, as enormous difficulties were encountered duringsoftware development and modification, as in the FAA program on its AdvancedAutomation System (AAS). Also programmes like AERA 2, that followed a technologydriven approach with elements leading to expelling the controller in the end, wereunder fire. The risks for failure seemed too high to be realistic solutions for theforeseeable time frame.

So, there were opponents and proponents for both a technology drive and a morehuman driven approach. The problem was how combine both in order to allowcontrollers to work more effectively and pleasurable, while still realising an increase incapacity. Or, as one of the future directors of Eurocontrol summarised it in 1993(!):

‘Despite new information and telecommunication technologies, no ATC project hasever been proven to be feasible and also to increase capacity’ (Garot, 1993).



2.4. DESIGN REQUIREMENTS

Within the overall PHARE programme, several projects were running in parallel. Allthese projects had to deliver specific deliverables in support of the overall programmegoals. 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 taskassigned to the project was to deliver the design of the Human Machine Interface. Inthe end, GHMI software was required to run the simulations. The production of thatsoftware was not a part of the GHMI project. This type of task sharing was clearlyunfamiliar to most of the participants in such a technical project, and many discussionswere 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 toolsunder development that had to be made usable for the controller, as full automationdid not seem achievable with a high level of certainty. The automation philosophy ofsuch tools were not directly ‘user driven’ but clearly technology driven, taking theopportunities provided by data links and the availability of more advanced computingfacilities. So, all kinds of duties could be taken from the controller without knowing ifthat strategy would still result in a workable environment for these controllers.

One point was however, clear at the time. Controllers were too busy now andsomewhere, somehow, some spare capacity had to be created in order to allow thecontroller to handle more aircraft in a given time period. Therefore, the GHMI designhad to focus on a reduction of overall workload (as compared with earlier systems) formost, if not all controllers of the future ATM system.

Given the highly philosophical discussions at that time, strong opinions on the rightway forward existed and many arguments were in place, being in favour or againstcertain road maps to future designs. Objective measurements seemed in order toprovide the basic data to structure such discussions and guide the decision process.

Experiments have a different goal as compared to demonstrations. The latter intentsto display certain features while the first intents to research the best solution out ofoptions available and based on objective criteria. The GHMI team was trained indefining and conducting experiments and served as advisors on validation issues andthe set-up of the demonstrations. Later in the programme, a more specific project wasdefined 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

• Design, specify and assist the development ofa more effective HMI

• Increase controller output• Realise ‘workable’ workload levels• Optimise application of PATS tools

• Provide empirical evidence of effectiveness• Subjective acceptance + Objective measures!

I

II

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

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. Thereason for this was that it took some time to realise that there would still be animportant role for the human operator in the future, and as a consequence humanfactors issues to be considered.

ATM CONCEPTS

SCENARIO’S ROLE OF MAN

AUTOMATIONTECHNOLOGY

GHMIDESIGN

INTEGRATE

DEMONSTRATE

The PHARE Process

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 workcould be identified. The first line was technical and concentrated on defining operationalconcepts 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 andassociated HMI design requirements. The process is depicted in Figure 2.

PHARE R&D structure

GHMI

PATS

OTHER

PD 1

PD 2

PD 3

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

Integration in the PHARE Process PHARE GHMI project, Final Report


These lines of work had to meet somewhere and the demonstrations were a practicalmeeting and harmonisation point for the deliverables. So, each project worked on itslong term goals and delivered specific products in support of targeted demonstrationson en-route, terminal area and multi-sector applications. These PHAREDemonstrations (PD’s) therefore served to create specific deadlines to comply with aswell 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 boththe technical and human factors domain.

The first line of research addressed the effectiveness of particular automationprinciples or philosophies. An example of such a philosophy is to provide a controllerwith advice on what actions to take. On one hand, this could reduce the taskloadtheoretically, but on the other hand it can also impose an additional task in case thecontroller is still in full command. In that case, the advice has to fit the ‘big picture’ andtherefore 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 specificautomation technologies or PATS software tools. So, before implementing harmonisedproducts, 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 parttook 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

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 theHuman Factors domain. So, normal steps like scenario, function and task analysis wereincluded in the process of a draft GHMI definition. After that, prototyping would be used totailor and test the proposals for effectiveness and acceptance. Experiments would be usedto compare different solutions on their impact on objective and subjective workload etc.After ‘iterations’ sufficient knowledge and experience should exist to decide on the formatand 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 afinal specification for implementing within the demonstrations.

3.3. THE DESIGN TEAM

Within such a collaborative project, many partners participate with differentbackgrounds and specialisms. Initially, all GHMI members were involved in the designof a particular system, i.e. the PD1 reference and advanced systems. Later in theproject, some overlap between several sub-projects projects, necessitating theformation of dedicated design and training teams. This set-up proved effective inachieving the deadlines and deliverables of the overall project. It is however, importantto assure sufficient transfer of knowledge and lessons learnt. This was achieved byhaving members in a team with experience from prior work and common GHMImeetings when required. A project of this scale involved many well motivated andhardworking individuals. The following persons were involved:

Design:

CENA: Didier Pavet, Nathalie Debeler, Christophe Mertz, Joel Garron

DERA: Peter Goilleau, Chris Kelly, Brian Hadford

DLR: Fred Schick, Haralt Derkum

EEC: Alistair Jackson, Isabelle Pichancourt, Emmanuele Jeannot, Daniel Tasset

NATS: Angela Lucas

NLR: Herman Nijhuis, Suzanne Buck, Dennis van Touw, Andrew Porter (DERAcontracter), Peter Jorna (project leader)

Integration in the PHARE Process PHARE GHMI project, Final Report


Training:

NLR: Marian van Blanken, Jan Joris Roessingh, Bas Kuypers

DLR: Andreas Hobein

CENA: Didier Pavet, Caroline Chabrol, Joel Garron, Florence Fichent andJean-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.

PHARE GHMI project, Final Report Human Machine Collaboration


4. HUMAN MACHINE COLLABORATION

4.1. 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 thatflight crews lost track of what the automation was exactly doing, the so-called modeawareness problem. This applies especially to situations were the aircraft is on ‘automatic’ and the crew is monitoring the situation. In monitoring situations it is difficultfor humans to maintain a sufficient level of ‘ arousal’ and attention to respondeffectively 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 withexisting technology. A problem with such an approach is that it does not necessarily fitthe normal line of events when working with the system as a whole. So, human taskexecution involves the use of multiple systems over time. If we take the flight deck asan example, navigation functions can be automated but the crews have to combinenavigation with communication. As a result they have to shift between differentsystems with different characteristics or behaviour. Incompatibilities can occur withrespect to ergonomics, leading to confusion and misunderstandings. In summary, atechnical approach to automation is biased towards developing a system or ‘box’taking care of some function. A human centred approach is more directed towards theway people perform (series of) tasks and procedures, taking into account that morethan 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 isanticipated, 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 acontroller. Tasks are allocated to either machine or human depending on factors such astraffic load, number of controller’s available etc.

Human Machine Collaboration PHARE GHMI project, Final Report


Adaptive: in this case it’s a second layer of automation that decides on the configuration.If traffic load is increased, or the controllers level of workload is relatively high, moreautomation is made active.

Advanced: in this case no existing task or function is automated, but technology is usedto 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 aresult, 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 humancontroller. To emphasise the human aspect, a ‘tool approach’ was promoted. Anadvantage is that a system can be equipped with many provisions and tools tailored ormodified to be compliant with the controller’s needs. Many system configurations arenow possible, while re-using the same essential technology. The word ‘Tool’ suggestsand implies that a controller has some control over using it or not. So, the automationconfiguration will be ‘adaptable’ to the needs at hand. Some of the tools developednever 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 butnot requiring strategic thinking, were fully automated whenever feasible. Data linkcommunication replacing radios is an example. After essential decision making, asoftware communications manager is capable of informing the aircraft fully ‘automatic’.

An important advantage of such a comprehensive approach is that a system can bereconfigured in many ways, without discarding the expensive technology or softwaredevelopment. So, a PHARE system can be modified easily to be ‘adaptive’ inresponse to a psycho-physiological workload index obtained from a controller. Theapproach taken in design was to integrate as much tools as possible into one genericworking position. This allowed experiments to assess the spontaneous use of sometools without forcing a particular working method on a controller. Only in very specificcontroller working positions, unique tools were added. After gathering the data, finalconfigurations and working methods can be defined, resulting in more validatedconfigurations that can be build more cost effectively.



4.3. TASK AND SKILL ANALYSIS

Often the wording ‘tasks’ and ‘skills’ are used interchangeably, but there is a distinctdifference. Performing the same task like’ hammering a nail in a piece of wood’ underdifferent circumstances can involve totally different skills. Imagine hammering in theopen air (no problem for most people) as compared to hammering ‘under water’ by adiver (wood floats and it is a bit dark). All is the same, except the environment andsuddenly something simple becomes very complicated. Similarly, the task of landingan aircraft requires different skills when performed under bad weather or night, orwhen it involves severe cross winds. In addition to these factors, time restrictions playa role in determining the required level of skill. When landing a general aviationaircraft, completing a ‘circuit’ and performing down wind checks with a slow aircraftrequires different skills, or levels of skills, as compared to a fast aircraft. If the circuitcannot be extended for noise abatement reasons, time pressure will be imposed on allthe checks and communications required. Planning and anticipation are suddenlyeven 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’ instead of the ‘skills’ required for the human operator. One reason for this bias is thecomplexity of identifying human skills as opposed to the relative ease of definingoperational tasks for the system.

In general, there are two major methods to analyse human tasks and skills dependingon being pro-active or re-active:

• Theoretical or analytical analysis: most often used when the system is not yet inservice or is being updated. Based on available system and mission scenario’sdescriptions, anticipated skills are identified and the training is prepared.

• Empirical analysis: most often applied when the system is in service andproblems are encountered with respect to attrition rates, performance levels and orselection issues. By observing and measuring actual performance (strategies) newknowledge 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 andskills of controllers.



Mission analysis

Function analysis

Function allocation

‘human’ ‘automation’

Operational analysis

HMI designssoftware

specifications

Operationalrequirements

time line

working environmentcontext

skills

training & selection

procedures

System and HMI design

human tasks

Behavioural andworkload 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 serveas inputs to the training (and selection) procedures. Note that the wording ‘scenario’ has beenomitted in order to prevent confusion. Normally, it is used by operational analysts in the block ‘missionanalysis’ and by behavioural analysts in the block ‘procedures’.

The first theoretic approach uses the familiar methodologies derived from ‘Mission andTask analysis’ as used in military system design. Based on insights on thecharacteristics of (future) systems, environmental context(s), tasks to be performed bythe human operators are defined. After combining the tasks with their contexts, skillscan be identified, clustered and grouped into training tasks (meaning the particularcombination(s) proposed to facilitate training progress).

The second method is more practical and uses observations and studies of humanoperator behaviour while performing their work in reality. The advantage of the lattermethod is that the environmental context is actually present, so critical interactionsand features can be defined or even measured objectively.

The estimated working conditions need to be considered very carefully in thetheoretical approach as they will impact on the particular difficulties that the humanoperator will encounter and by that have a strong influence on the ‘real skills’ involvedin successful operations. Team factors are often overlooked.



The methods mentioned are often leading to confusions about what task analysis is allabout and for that reason a short overview is presented. The aforementionedprocedures are not to be considered as mutually exclusive, but as complementary.They are both part of a more comprehensive overall methodology, which is alsoapplied for other purposes like the design process of the system itself. Part of thisprocess 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 thetraining design. However, in reality, designs are often driven by technologyapplications 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 manydifferent, 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 stillnot specifically related to an individual. The problems start to occur the moment thatthe individual operator strategies and the resulting variations in human performancelevels have to be considered, i.e. effects of practice, experience, individual abilitiesetc.

The creation of a so-called ‘time line’ implies a specification of which tasks have to beperformed at what time and it what order. So, essentially working procedures arespecified. In reality, it is well known that persons will take shortcuts, invent newstrategies etc. Predicting for instance ‘workload levels’ is very hard when thesestrategies are not considered or still unknown. So when defining the ‘skills’ required,possible variations in human behaviour strategies have to be considered and whenpossible, tested in prototypes. This kind of data is hardly ever available, so with goodreason, training factors impose a clear emphasis on addressing the characteristics ofthe trainee (future users) and on the consistency of the training required. Both of theseelements are not present in the above illustrative model and form a unique feature oftraining analysis.

A major issue encountered in the programme, was the uncertainty about theoperational procedures. The Operational Task force (OTF) had great difficulty indefining a commonly agreed working procedure. Therefore, the GHMI team had toinvent such procedures based on capabilities of the tools and characteristics of theGHMI. This made the iterations more complex as compared with a situation were themajor 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 logical-temporal description of the possible future working activity (or dynamic aspect of thetask) of the controller and the involvement of other controllers, in other words the tasksharing. Note that other actors such as pilot or supervisor may be mentioned asinterlocutor. The interest of this formalism is to be open and to enable differentdimensions of description.



The TLD approach can support the whole process from the Task Analysis to the HMIspecification. In an early phase, the TLD do not yet refer to any HMI, it is only in a laterform that Tasks are described from a HMI point of view. Hence, an HMI input could bea controller action (i.e. using the mouse) and an HMI output could be a display ofinformation such as an updated trajectory. System processes (i.e. processesperformed 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 thesoftware design teams.

One of the interests of such a multi-dimensional description of the task/human activityis in its possibility to show the flexibility of the HMI in case the same task may beachieved via different procedures using different HMI facilities or tools. Anotherinterest of TLD is in its ability to give a view of the complexity of the task, via its type ofstructure (i.e. sequential, parallel…), its number of tests required, its number ofprocesses/actions required, etc.. After selection of the route through the HMI (interfacenavigation), a timeline can be constructed to study bottlenecks, inconsistencies etc.

Each diagram takes the form of a flowchart referring to the overall processesperformed either by the HMI, the system or by the controller without the system. (Anoverview of the TLD formalism will be discussed shortly).

Planning:

A first set of TLDs was delivered during the Task Analysis Phase carried out by theGHMI Design Team in 1996 (GHMI Specification for PD3 - Part 1 -PD3 ControllerTask Logic -August 96). In the final and complete version delivered as Annex B of theGHMI Specification version 2.2 (January 98), the detailed activity was described forthe 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 finalapproach)

The Operational Task Force group (OTF) had produced a description of the roles andintended tasks for the controllers. This served as a major input for the GHMI PD3Design Team and intensive collaboration was established with the PD3 OTF. Whenthe OTF agreed on the overall procedures, the TLD’s were produced jointly with ‘Inhouse’ Operational experts of each centre.

It was intended to be a ‘Living document’. The content was refined as the GHMIspecification evolved up to the version 2.2 (before the demonstration started).

Ideally, as the final PD3 GHMI specification, the TLD document would have beenupdated at the light of the final demonstration result. It has to be reminded that inaddition to the HMI, the working methods are part of the validation process. Thepertinence of a new operational concept relies as much on the task sharing amongactors as on the HMI adequacy to the task.

Overview of the Formalism:



With the formalism used, the HMI is considered as an object with two sides: the Userside and the System or Applications side. From each side what comes in and whatgoes out is shown by the direction of the triangle relative to the HMI itself. The boxeswith an ellipse inside represent the User side; the boxes with vertical lines parallel tothe box sides represent the Application side.

(Note that a box with nothing inside (except text) shows that this activity does notimply the use of the HMI, e.g. the direct communication from the Controller to the Pilotby R/T. (Figure 7).

Trajectory Edition

TP compu- tes new trajectory

CP detects a urgent conflict

USER SYSTEM

STCA is displayed

HMI

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

Figure 7: User / System division in the TLD specifications


OC 99-70-02 Version 1.0 / August 1999 -31-

Illustration: Description of the Task of Trajectory Edition

ERLevel III

Edit Trajectory via TEPS

Activate TEPS on required

aircraftStart

Select appropriate

Trajectory via TST

Add or manipulate route constraint in

RPVD

Add or manipulate Altitude constraint in Profile Window

Add or manipulate Time Constraint in RPVD or Profile

window

Is Wtraj Satisfactory?

Validate Wtraj via TST

TP generate trajectory using TEPS constraints

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

Display chosen trajectory in RPVD

TEPS & Profile window

Subordinate Task

Yes

No

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 ofthe HMI User side. A user command always provokes a display of data. With certainfunctions, the process is only within the HMI User side e.g. a zoom of the Radar PlanView Display. Otherwise most of the functions imply the processing of data by a part ofthe ATM Software Application. The HMI System side carries out the dialogue of theHMI with these processes. A user command provokes a call to a specific dataprocess, it is an output of the HMI Software System side, e.g. when the PC edits atrajectory, the Edit Command requires the use of the TP. (Trajectory Predictor). Whena data process works continuously, as the STCA (Short Term Conflict Alert), itprovokes a call to the HMI System side to ask the HMI User side to present/display theprocess output to the controller. Note that the way data is processed and which partof the software application is responsible for this processing is not always evident,especially for non-software specialists. Consequently, at an early stage of thespecification process, the description might be rendered only in terms of data andprocesses carried out by the HMI User side. The aim of the specification process isthe definition of the best possible interface from the user point of view. Following thisobjective, human activities (and requirements) will, initially at least, be more detailedthan those for data processing.

At a later stage, if some limitation in term of data process, or in terms of integration ofdata from different processes is identified, it may be interesting to show this explicitly inthe schema. For example, different tools assisting the Trajectory Editing can usedifferent TPs so the output presented to the user may be different.

Act iv i ty wi thout any l ink to HMI appl icat ion

HMI User s ide (L ink be tween HMI d ia logue

and User )

HMI Sys tem s ide (L ink between HMI D ia logue

and ATM appl icat ion)

Figure 8: Different types of dialogue

Note that the HMI User side will be specified in as much detail as possible but theSoftware Application side will be treated as a black box. Its detailed description isunder 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 termsof a Task Description Form defining the actor(s), goal to be reached, informationprocessed (e.g. input and output), triggering and stop conditions, properties such aspriority, Back/ foreground task, etc… In practice, the result of the task description wasdirectly embedded into the GHMI specification either in a specific chapter definingmain 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 anddialogue description.

The Task Description should generate the system function requirement that serves asinput to the PATs software team defining information and processes required. Whenthe task analysis started, most of the tools were already specified and evenimplemented. The GHMI DT had to understand from the documentation availablewhether the user requirements were compliant with the task analysis. This wasfollowed by endless adjustments between operational and technical requirements.

Report Title Chapter title


Additionally, with so many specifications (i.e. about ten CWPs to be designed in bothBaseline and Advanced Organisation) it seemed necessary to have a ‘Matrix ofObjects’ emphasising the commonalties and specificity of every operational datastructure 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 betweenPATS and GHMI and a better tools integration.

In the absence of feedback from the PATS people, the use of TLD as an input for thenormal software oriented ‘user requirement document’ completion can not beconsidered as proven yet. TLD utility and usability for the software team has certainlyto be improved. A better interface with software developing methods would improvethe 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 ANALYSISREPORT 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 allowingdynamic simulation and easier navigation, coupled with Task Description Formmanagement.

Given the constraints in planning and how work was allocated across the GHMI DTpartners, specialisation was inevitable. Consequently, extended and systematic cross-validation within the OTF team and with external operational experts did not alwaysoccur. For a more harmonised European HMI, much additional work must beundertaken.

PHARE GHMI Project, Final Report Results


5. RESULTS

5.1. EXPLORATORY STUDIES

The aim of exploratory studies was to gain practical experience with some HMIfeatures and facilities that probably would become a part of the final design. As anexample, 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 theuse of cockpit and ATC data links were studied in many national and internationalprojects. Also the use of advisories was under discussion as there was a possibilitythat such presentations would change the type of skills needed or could evenrepresent additional work for a controller handling high traffic loads. It was thereforeessential to acquire some background data to assist the harmonisation and decisionmaking of the following integral design process. Some of the results, for instance oninput devices, may be superseded by more recent material. They are still mentionedfor historic reasons and to provide some background on why some design selectionswere made.

5.1.1. Input devices

• Introduction

The aim of the DERA study was to compare the speed and accuracy of variousmechanisms of inputting data in an ATC system.

In the light of the above it was decided to carry out an experiment comparing four inputdevices:

- 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. Anoptical type of mouse was not used because of the disadvantage that the surface hasto 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 thescreen, and the a following mechanisms were compared:

- Scroll menu: To make an entry on the scroll menu the user clicks on the selectedvalue. To scroll up or down by five values at a time the user clicks on the arrows atthe top and bottom of the menu.

- Press and drag menu: to make an entry on the press and drag menu the userreleases the mouse button over the selected value. To scroll up or down by onevalue at a time the user drags the cursor over the arrows at the top and bottom ofthe menu.

- Virtual keypad: To make an entry the user clicks on the appropriate keys shown onthe keypad.

- Elastic vector. To make an entry the user drags the end of the vector round to thedirection of the required heading and releases the mouse button.



Figure 9: Input mechanisms for the experiment

• Experimental tasks

The participants were asked to enter a series of flight levels and a series of headingsusing each of the above input devices and input mechanisms. The aim of theexperiments was to assess speed, accuracy and ease of use of the input devices andmechanisms.

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 onthis value. This option models the safety approach in which an inadvertentlyentered new flight level will be the same as the current flight level by default andthe 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 controllerwill most likely clear an aircraft to its exit flight level if possible. Hence the speed ofthe input action is increased when the menu is defaulting to the appropriate value.

Finally three different types of selection were used:

- Implicit selection: the selection button is automatically selected when the cursormoves onto the button.

- Explicit selection without visual feedback: A mouse button has to be pressed whenthe cursor is over the button to select it. The button is not highlighted as the cursorenters it.

- Explicit selection with visual feedback: A mouse button has to be pressed when thecursor is over the button to select it. The button is highlighted as the cursor entersit, thus indicating the acquisition of the button.

• Results

Results PHARE GHMI Project, Final Report


The median time for each device for each entry value was first obtained. Using themedian rather than the mean, reduced the effect of individual values which causeproblems, for example where the participant took several attempts on one occasion toenter 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.) Mouse Trackball Puck Stylus

Errors 11 13 6 18

Inputs 800 800 800 800

The next table shows the median results for the time taken to press the selectionbutton (tsb) with different button sizes. The smaller button and the track ball bothappear to result in longer time being taken to press the button. The other three inputdevices all result in approximately the same median time to press the button.

Timing (sec.) Mouse Trackball Puck Stylus

Small button 1.96 2.89 1.96 1.94

large button 1.83 2.53 1.80 1.74

• Comparison of input mechanisms

As with the comparison of input devices, the median for each data value over allparticipants was obtained:

- scroll menu;

- press and drag menu;

- elastic vector;

- virtual keypad.



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 beneeded, depending on the entry values. This extra action has a major effect on thetime 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 entrieswhere the new value was close to the original, required fewer steps than those wherethe new value was remote from the original.

In each case heading(s) were being entered, using explicit selection with visualfeedback, small selections buttons and the menu centred on the current heading. TheFigure shows that the elastic vector was slower than other mechanisms. There are twopossible explanations for this, one applies only in this study, the other to all elasticvectors used for heading input. In this study, due to time constraints, only one out of20 conditions used the elastic vector. Participants may not therefore have become asfamiliar with the mechanism as with other mechanisms. The second possibility is thatthe dexterity required to drag the end of the vector round to the appropriate angle isgreater 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 participantstook a longer time to enter this value than those around it. The results where elasticvector was quicker are probably those where the distance the vector had to bedragged was small, i.e. the new heading was close to the current heading.



• Conclusions

One conclusion was that the track ball (note that different types are available withother characteristics) was slower than other devices, both in moving across the screento a small target and in entering a flight level from a menu. The experiment yieldedvery few errors; therefore there was no perceived difference in accuracy between inputdevices.

The menu appeared to be the best mechanism, however, the dramatic increase inentry time associated with scrolling the menu shows the importance of avoidingscrolling by intelligent centring of menu when it pops up.

Based on such exploratory studies, it was decided to select the mouse and the menuformats for further prototyping. The mouse, because of its increasing user familiarityand easy availability. A trackball has certain advantages for more operational systems,like maintainability, robustness etc. but it needs careful calibration to obtain a goodbalance for larger and smaller movements.

5.1.2. Gesture recognition

As a future alternative to menu’s etc., an experimental technique was explored byCENA that would allow the controllers to write their inputs. So instead of selecting froma 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) addressedthis 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 forradar image management (zoom, pan), gestures for flight labels and fields andgestures for numerical inputs.

The results of controller evaluations were unexpectedly positive. Gestures were ratedas more ‘natural’ and less demanding than mouse inputs. Users were sceptics at thebeginning, but after twenty minutes (!) of use they all felt ‘ confident and cool’.

Due to time restrictions in the programme, further investigation was halted, as gesturetechnologies were not foreseen for implementation at the medium term. The techniqueseems promising for future application.

5.1.3. Controller data link interface

Datalink communication in this NLR study can involve computer-computer interfacingas well as Air- Ground human operator communications. Pilot can request routechanges, ask for information etc. while the controller can detect possible conflicts inthe future and provide the aircraft with instructions. Finding and implementing aresolution in the present day systems often requires vocal communications with thepilots as well as inputting data (the instructions) into the ATC computers in order todisplay the overall status to the controller.



KLM123153â120 100402 280 250B747 045 010

SPD

Send

s

370

360

340

330

320

t

button

scrolling

350

plot symbol310

send

FL SPD WP HDG

370360

340

330

320

350

310

370360

340

330

320

350

310

SPLHSTHEL

040

Pop-up menu’s for single andmultiple ‘on screen’ inputs

Figure 11: Examples of data link user interfaces that allow direct selections andtransmissions of solutions of problems and instructions to the aircraft.

A data link user interface can accommodate both these functions at the same time. Inan experiment, different versions were developed and implemented for testing underhigh and low traffic loads (Hooijer & Hilburn, 1996). The data link can be implementedas a separate communications window on the controllers display or as an integratedpart of the so-called radar plot symbol that is associated with a particular aircraft.

Examples of such selectable pop-up menu’s are depicted in Figure 11.

Similarly, the feedback of actual status of the negotiations with the aircraft need to beprovided as data links have a time delay in transmitting the data, depending on theparticular medium used i.e. radio frequencies, radar signals etc.

The feedback can be provided through different means. Integrated with the radar plotdata block or as a separate communications window. Examples are shown in figure 3.



Feedback of datalink status

KLM123153 × 120 100402 280 250B747 045 010

plot symbol

s46

= uplinked (green)

= acknowledged (green)= unable (red)

s= no response > 30s. (red)

Figure 12: Examples of means for providing feedback on the data link status forcommunicating and receiving confirmations from many different aircraft.

From these options three combinations were designed that will be designated as userinterface combinations ‘A’, ‘B‘ and ‘C’. The mapping of the particular features that werecombined is as follows:

Condition Input method Feedback

A pop-up menus DSP

B pop-up menus label symbols

C combined pop-upmenu

label symbols

The conditions A, B, and C were intended to represent an increasing level ofintegration 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 facilitatedthe subsequent integration of data and information. These options have differentdisadvantages. As an example, the data link status window will change in content (ir-)regularly, thereby attracting the controller’s attention at a time that such informationwould not strictly be required for mental processing. Alternatively, the pop-up or better,pop down menu’s 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 gazemeasurements, head tracking, pupil size, heart rate and respiration, heart ratevariability, logging of system inputs and responses and extensive use of subjectiveratings. 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:



Heart rate variability is a workload sensitive measure that normally decreases whenpeople are working under conditions that are cognitively loading or stressful (for areview see Jorna 1992). So a user interface that is easier to work with could result in arelative increase as compared to more cumbersome interfaces. However, no veryexplicit results were expected, as Heart rate variability is especially sensitive to themore extreme overall working conditions that are associated with particular distinctivemental states as associated with mental work and stress.

The results obtained in this experiment proved very promising as indicated in Figure13.

Objective measures: Heart ratevariability

4.2

4.4

4.6

4.8

5

5.2

5.4

5.6

5.8

A B C

0.1

Hz

com

po

nen

t

LowHigh

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

Objective measures: Pupil size

33.13.23.33.43.53.63.73.83.9

4

A B C

Siz

e in

mm

.

LowHigh

Figure 14: Pupil size decrease (indicating less effort) as a function of controller datalink interface and traffic density (Low or High).

The impact of traffic density on heart rate variability is quite consistent and also distinctfor type of user interface.



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, thepupil size was calculated and analysed. The results of this analysis are depicted in theFigure 14.

The size of the pupil(s) is also modified by physical factors like the amount of lightpresent, but visual information sampling and mental processing of visual data alsoinfluence it. In that case, its size will increase as a function of the amount of visualinformation processing. With more light, it will decrease.

The results indicated that accurate measurements of small differences in size could berealised. Similarly to the heart rate variability data, the workload as indexed by thepupil decreased in size as a function of integration in the data link interface. Itincreased markedly with an increase in traffic density (difference between Low or Hightraffic samples). Note that more traffic implies more radar plots on the screen, whichshould 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 inFigure 15.

Subjective measures: NASA TLX

0

1

2

3

4

5

6

7

8

A B C

TL

X s

core

LowHigh

Figure 15: Ratings provided after the experimental sessions as a function of controllerdata 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 thisexperiment the objective results all pointed to the possibilities of designing effectivecontroller data link interfaces, but the subjective data did not reflect this to the sameextent.



5.1.4. Conflict detection and resolution tools

The mental processing capabilities of the air traffic controller are generally consideredto represent a major bottleneck in expanding the amount of air traffic. One reason isthe communication process that is of a serial nature and has to address each planeindividually. Also, the controller has to build an overview over the traffic streams inorder to be able to predict and anticipate possible separation issues. In case of apossible overload, the traditional procedure is to subdivide more sectors so morecontroller teams can share the work. The disadvantage is of course that thecommunication requirements also increase dramatically, thereby limiting the overalleffectiveness.

Alternatively, the use of data links allow the controller to issue messages to bothaircraft and other centres and both individual aircraft and groups of aircraft can beaddressed if relevant. Also, clearances with multiple parameters or complete routeinstructions can be issued. Software tools can provide assistance in conflict detectionand resolution of aircraft route or altitude infringements. The effectiveness of suchpossible assistance was investigated by means of simulations and extensive objectiveand subjective measurements (Hilburn et al. 95, Hilburn et al. 96).

The results of a comparison of a stepwise increase in the level of assistance providedwith a ‘manual’ baseline are depicted in Figure 16 for pupil size measurements.

Effect of automation on pupil size

Manual Detection

.25

.75

.50

1.0

Low trafficHigh traffic

Pu

pil

dia

met

er (

Z s

core

)

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 thesemeasures. Also, the results for Heart rate variability revealed an almost identical trendwith heart rate variability increasing systematically when more assistance is providedto the controller.

An additional technique applied was the principle of ‘dual tasking’ but with the purposeof acquiring an objective measure of situation awareness, in this case defined asawareness of communication and aircraft status. Incidentally, aircraft would fail toacknowledge they’re up links and the controller had to detect these occurrences. Incase of a reduced overall task load, more options are present to perform this particulartask more timely. The results are depicted in Figure 17.



Detection of ‘unconfirmed’ uplinks

Res

po

nse

tim

e (s

eco

nd

s)

10

50

30

20

40

Manual ResolutionDetection

low traffichigh traffic

Figure 17: Controller response times to status information on communications andaircraft responses.

Apparently, the tools do allow the controller to scan the display more effectively,resulting in better overall performance. So, overall the objective measures clearlyindicate the potential of the tools in helping the controller. But how do the controllersrate them subjectively? That data is depicted in Figure 18.

Subjective workload ratings

0

5

10

15

20

Manual Detection Resolution

high trafficlow traffic

Figure 18: Controller estimates of workload effects as a function of more softwaretools.

Surprisingly, the controllers rate the effects of the tools quite contrary to the pictureprovided by the objective measurements. Possibly, the addition of extra functionality isexperienced as more work to be handled. Alternatively, their ratings may be influencedby the relative unfamiliarity with the automation. Essential is that subjective ratings canbe influenced by many other factors than task loading alone.



5.1.5. Arrival sequence tool

A mediating factor in these ratings could be the particular strategy employed by thecontrollers in using these tools. Controllers have very particular strategies in handlingtheir traffic and these ‘controller methods’ could influence adaptation to the newcontroller working position. Analysing the eye scanning during high and low trafficdensity samples can provide an illustration.

ATC plan view display (PVD)

RIVER

IBE 326IBE 326

AMC 282

AMC 282

05

10

15

Time line

Hand-off

Datalink

Traffic

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 area’s are usedby the point of gaze equipment to provide area related data on eye scans, duration’s,transitions etc.

The present study (Hilburn et al 1995, 1996) investigated the human use of possibletools 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), seeFigure 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 andSTA agree;

- Traffic area– the region of the screen in which controlled aircraft appear, includingboth the aircraft location plots, and the flight labels that display all relevant flightparameters;

- Data link Status Panel– displays all recently-uplinked messages, together withelapsed time since transmission, and whether the clearance has yet beenacknowledged by the aircraft;

- Hand-off region– general area in which the PVD displays the plots and flight labelsof 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 theyare accepted from the previous sector. Viewing this region provides the controlleran indication of impending traffic load changes.

The results of the ‘point of gaze’ measurements are depicted in Figure 20.



36.7

4.9

7.6

7.8

15.7

TL

TRAF

PRE-ACCEPTANCE

HO

D / L

(409.0)

(620.2)

(584.3)

(672.9)

(484.1)

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

44.6

4.5

1.84

9.0

14.9

TL

TRAF

PRE-ACCEPTANCE

HO

D / L

(405.8)

(611.7)

(604.7)

(664.5)

(546.7)

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

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 influencedthe visual scanning of the task-relevant surfaces. It appears that average dwell timeswere slightly influenced by differences in traffic load. Surfaces 1,2, and 4 (i.e., thetimeline, traffic and hand-off regions) showed a decrease of 0.8% to 1.3% from low- tohigh-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 pre-acceptance 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



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 isused 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’ controllingmethods. The paradox that occurs is that tools with technology designed to ease thejob of the controller are being discarded especially in the situations where they wereanticipated 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 thebenefits of working with multi-disciplinary teams. The 4D concept could be visualisedby imagining tubes in the sky containing a certain time bubble were the aircraft wasplanned and contracted to be in during the flight. Two numerically blessed persons,Meckiff and Gibs, came with the wonderful idea to mathematically describe andanalyse the interactions between such tubes. These interactions could be plotted onthe individual dimensions like lateral, vertical and the time dimension. A next step wasto develop displays for such interactions, which would allow the controller to gaininsight in the traffic intersections and decide on actions to be taken. This idea wasenthusiastically adopted by the GHMI team, but met quite some initial resistance in theATC community. One reason for that was the use of abstracted displays that allowed apeek in the future. Also the original name for the function developed, was problemsolver, and the HIPS was critiqued for not providing ‘automatic’ solutions. So, it wasan example of an automated function that evolved into a tool for the controller, byreworking 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 toolcomprises two main components: a set of displays, which give a comprehensivepicture of air situations, and an aircraft trajectory editor. These are coupled together toallow route, altitude and speed manoeuvres to be evaluated and implemented in anycombination on any aircraft. 'The Problem Solver itself is not an autonomous unit (itdoes not solve problems by itself, but rather is an interactive tool for use by the air-traffic controller For this reason the concept has been named the Highly InteractiveProblem Solver (HIPS).

• Display of air situations



The HIPS concept proposes abstracted diagrams as a novel approach for the displayof air situations. These are 2D graphical representations of aircraft and performancelimits, which present the controller with information in the form of time-independent 'no-go' zones for a chosen subject aircraft. Such 2D displays are an abstracted form of a4D geometric model of intersections, projections and transformations. There are threeforms of abstracted display: route, speed and attitude, corresponding to the threetypes of basic manoeuvre available to the controller. The most important of thesedisplays, the route display could be superimposed upon conventional synthetic radaror conflict assistance displays. The speed display, on the other hand, provides a quitenew perspective, directly showing the effects of manipulating the speed of one aircraftrelative to others. This opens up the possibility of using small speed adjustments tosolve conflicts - a little used option until now.

• Trajectory editing

HIPS provides the controller with the possibility to manipulate trajectories in order toavoid the no-go zones displayed on the abstracted diagrams. Solutions may be rapidlyachieved due both to the clarity with which the air situation is presented to thecontroller, allowing possible solutions to be quickly identified, and the simplicity of themouse operations required to change the trajectory. These displays also provideadditional guidance to the controller in the form, for example, of aircraft performancelimits to help him achieve a near optimal solution.

Trajectories to be edited need not necessarily be those of aircraft in conflict. It ispossible for a planner, for example, to rapidly check whether an off-route or direct trackis feasible for a particular aircraft traversing his sector. 'This could allow systematicoptimisation 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 4Dgeometry, follows:

It is possible to mark on the track of an aircraft's predicted trajectory the sections forwhich that aircraft will be in conflict with another. If an alternative trajectory(representing, for example, a heading change) is drawn alongside the original, theconflict could be marked in a similar way for that trajectory. If a closely packed seriesof 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 displayedto the controller.



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 theirtrajectories. The controller wants to ensure that they remain at least 5 nautical milesapart. Computations can rapidly be performed to compare the two trajectories todetermine at which points, if any, they come within a margin of 6 (= 5+2*0.5) nauticalmiles.

If one of the trajectories, that of the subject aircraft, is drawn on a display, the sectionin conflict could be highlighted with a thick line. If the controller wishes to change theheading of the subject aircraft in order to resolve the conflict he may select the point atwhich the aircraft should turn, and propose a heading change. The new trajectory canbe redrawn with the conflict line marked again if it is still present. The controller may trya number of possible headings until he finds one with no conflict - this represents apossible solution to the conflict. Note that during this operation it is possible that forsome proposed headings the aircraft would come into conflict with a further aircraftand a conflict line caused by this third (or nth) aircraft would appear somewhere elseon the trajectory.



trNo-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 aircraftplotted with time along the x-axis and distance along the y-axis, so for a trajectory atconstant speed the display shows a straight line with a gradient equal to the ground-speed of the aircraft. Once again the parts of the trajectory for which the aircraft is inconflict with environmental aircraft can be marked (Figure 25). A speed changecorresponds to a change in the gradient of the line with the start point fixed, andconflict lines can be swept out by moving the line to form conflict zones as before. Thecontroller can choose a speed profile on this display to avoid the conflicts.



Figure 26: One of the early prototype heading displays in the HIPS. Note the variousshapes of no-go zones.

The diagrams given above show fairly simple no-go zones for each of the three typesof display: in reality the shapes of the zones can become quite complex! Within theGHMI project, they were named ‘blobs’ in an attempt to do justice to their complexshapes.

5.2. THE GHMI TRAINING APPROACH

5.2.1. Initial training approach

In all PHARE demonstrations/experiments (PD/1, PD/2 & PD/3) air traffic controllersare participating. These air traffic controllers have to learn to work with the system, itsHMI and understand the underlying concepts. So training is needed. This sectiondescribes the set-up of GHMI training for the three demonstrations.

The purpose of the training was twofold. First it was necessary to familiarise thecontrollers with the overall GHMI and its mechanisms. It was observed in early PD1trials that controllers would be distracted from their work during the experiments incase 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. Incase a mistake was made, confusion could occur. Subsequently, no adequateexperience was gained on the advanced tools. As a result the subjective estimates ofthe usability of such tools could be compromised. Practice on the GHMI basicstherefore improves the overall quality of the data obtained in the experiments.



The second reason was to familiarise the controllers with the fact that the experimentaddressed an experimental system and not a pre-operational system. In case of thelatter system, it is important to note all details relevant for day-to day work. Examplesare ergonomics of seats, screen layout optimised for local situation etc. In the PHAREexperiments 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

Central to the training are clusters of skills associated with:

- 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 training for PD/1 and PD/2 was set up as follows:

- The first part of the training took place on workstations, in which the HMI of the realsystem was adapted. Step by step, the different tools in the system became activeand could be learned and practised, guided by a paper explanation (1st

demonstration) or by explanations and instructions displayed in a window on thescreen (2nd demonstration). The lessons consisted of an explanation part and apractice part. Feedback was given by instructors/coaches (1st demonstration) or bysimple 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 whichthe focus was on team training. The system resembled the real system, but did notcontain features such as communication with (pseudo) pilots and the use ofheadsets. The use of the real system in different situations from simple to complexwas practised.

- The last part of the training was given on the real system (the actual demonstrationsystem), focusing on applying the learned knowledge and skills in practice. Further,practice features as headsets and communication with (pseudo-) pilots wereadded.

• Lessons learnt

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

- HMI familiarisation is needed for improving the overall quality of thedemonstrations by helping the controller to work the system.

- Massed practice does not work as effective as distributed practice in the first partof the training.

- Sending preparatory (paper) material to controllers in advance helps inunderstanding the system and speeds up the learning process.

- The initial acquisition of knowledge and skills by a computer integrated training asused in PD2 is worthwhile and gives positive transfer to the simulator and the realsystem. Computer based training should be developed and explored more.

- Use of paper reference guides and an AID MEMOIR, that summarise the systemcharacteristics (on-screen), working procedures and tools is very useful in thesecond part of the training on the simulator.



- Free navigation through the CBT and practice of interactions as often as wanted isnecessary in learning such a complex system.

- Explanations, interactions and reactions of the system should be integrated andfocused around the interaction of the controller.

- A performance monitoring system with a good test and feedback structure isneeded in the beginning of the training.

- Self-discovery/ freeplay moments are very useful in the later stages of learning, inwhich 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 twodemonstrations with additional improvements. The training for this last demonstrationtook 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 apersonal computer. This package was designed to support overall training and itsfunctionality’s with respect to active simulation capabilities were naturally limited. Theuse of a stand alone ATC system for completion of the local training proved feasibleand beneficial, as it includes exactly all the local GHMI details concerning sectors etc.Note that a systematic and structured approach towards training is always essentialand such an approach needs to be based on a training needs analysis and a skillbased training system specification. In the PHARE programme, a combination oftraining ‘systems’ was explored.



• PD/3 training organisation

The training for the third demonstration was set up as displayed below.

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

on simulator

The first part of the training computer based training (CBT) on a PC is used in whichfamiliarisation with the HMI and system concepts are learned. CBT has also thecharacteristics needed to improve the first stage of learning: performance monitoring,integration of knowledge and skills, individual pace of learning and independent oflocation. Further, the CBT can be used in a distance learning event (at home or at theATC centre, instead of at the demonstration site), as preparatory learning material.

Each (set of) CBT lesson(s) was rehearsed on the ATC simulator immediately afterhaving completed the CBT lesson(s) for HMI rehearsal. After having completed allCBT lessons, the second part of training took place on a high-end ATC simulator. Thistraining system resembles the real system, but has no features such as (pseudo) pilotsand headsets. A handbook is used to structure the training on the simulator. Thehandbook consists of paper reference guides for interaction with the tools and workingprocedures. A coach monitors the performance and gives guidance, help andfeedback where needed. The training starts with progressive part task training andends with sessions in a whole task training.

Computer Based Training on PC• HMI familiarisation & Concepts• Integrated explanations & interactions• Tests & feedback• Practice and rehearsal as often as

needed• Distance learning (anywhere, anytime)

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)



• PD/3 training instructional principles

In the computer based training on the PC, step by step system tools will be explainedand interactions can be practised as often as wanted (part practice). In the figurebelow, a screen dump of the CBT is displayed. Explanations and interactions areintegrated: 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 helpexplains 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 itemfeedback is given and advice is given on which parts to rehearse.

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

Computer Based Training

During the subsequent training on the ATC simulator, the use of the system in differentsituations from simple to complex will be practised and experienced. The ATCsimulator has pausing and replay possibilities of scenarios. Learned knowledge can beaccessed through the paper reference guides in the handbook. The coach, eitherduring practice or in little debriefing sessions gives feedback after completing a trainingpart.

To summarise, the training on the ATC simulator consisted of three parts:



- Rehearsal of interactions because they are not yet experienced in the functionalityof 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 simpleto complex.

- Team training, in which the working procedures are practised in a team andspecific co-ordination procedures are learned.

5.2.3. Training benefits

The integrated Training approach combining part task and full mission training on thestand-alone systems was generally regarded as very essential for the success of theprogramme. The HMI’s are quite complex with a wide range of facilities to be used byusers 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 nearfuture, but nevertheless, dedicated training is needed for working with newexperimental systems.

A positive side effect of the CBT part task training was that it could be distributed to allkinds of interested parties, before the actual experiments. The software wasdistributed on CD and could be used on home PC’s. This strategy proved highlyeffective in improving the overall participation in and acceptance of advancedconcepts. 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 achievedtheory by the participant. In that way all participants start the sessions with a commonbase level of understanding.

A negative aspect of the CBT is that the available authoring tools are essentiallylimited in their capability to include live simulations. When used for distant learning,ideally some coaching function should be included. Further development of authoringtools is clearly needed to create more options for the training designers to reach theirtraining goals without being forced to work around computing limitations. A firstexposure, 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 factorsexpertise, proved useful as their background allows them to effectively ‘detect’ thatsome procedure or tool was apparently not adequately understood during practice andtherefore, artificially, not being used by the controller. Remedies could be providedquickly and individually, allowing the controller more freedom of selecting controloptions available.

A continuation of the training approach is highly recommended. Future researchshould extend the scope of the training tools available and integrate its facilities into afull comprehensive set that would support experiments and could be re-used /modifiedto facilitate the transitions to the new equipment configuration.



5.3. THE 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 humanwould retain the ultimate authority for ensuring the safety of all flights. The currentcontroller roles of ‘planner’ and ‘tactical’ were therefore retained. No paper orelectronic flight strips were used; instead, the information was presented to controllersthrough interactive track data blocks and sector inbound lists displayed on thecontroller's main radar screen. The PD/1 baseline concept contained some simplecomputer assistance tools.

The operational concept was based upon aircraft having modern flight managementsystems 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 dimensionalpath in space whilst arriving at specified locations at specified times. When an aircraftfirst enters the airspace the pilot would datalink details of the requested trajectory tothe planning controller on the ground; typically, such a trajectory would cover the next20 to 30 ‘minutes of flight. Using the computer assistance tools the planning controllerwould check for conflicts with other aircraft and, if any were found, suggest a differenttrajectory to resolve the conflict. The alternative trajectory would be sent back to theaircraft to check that it could indeed fly the requested path. Once the trajectory isagreed by both pilot and controller, it would be input to the aircraft's flight managementsystem which then flies the aircraft along the trajectory whilst being closely monitoredby the pilot. The ground surveillance system would monitor the aircraft's actual flightpath and warn the tactical controller if any significant deviations were detected. Thecontroller 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 timeconstraints. These aircraft would also not have the avionics systems necessary toallow the dialogue between the ground and the airborne system. In such cases theground system would calculate a 'good' trajectory for the aircraft based on its type, itsorigin and destination, it’s altitude and other factors. Again, the proposed trajectorywould be checked by the planning controller to ensure it was conflict free, and modifiedif necessary. For those 3- D aircraft without datalink facilities, individual clearanceswould be passed, at the appropriate time, to the pilot by the tactical controller over thevoice R/T channel.



• PHARE Advanced Tools

An ATC system such as that implemented in PD/1 depends critically on the controllerhaving appropriate computer assistance tools. To implement the system as describedabove, the ground system must be able to predict where the aircraft will be in thefuture. The controller must be able to tell whether the predicted trajectory will be inconflict with any other aircraft's predicted trajectory; and the controller must be warnedwhen an aircraft is not following its agreed trajectory. To perform these tasks a numberof 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 theairborne Experimental FMS (EFMS) to predict the trajectory of the aircraft. The groundTP uses a database of aircraft performance characteristics, the initial flight plans andtrajectory constraints entered from the GHMI to generate close-to-optimal 4-Dtrajectories 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 iscapable of forecasting an entire flight from take-off to landing, in PD/1 the forecastswere 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 flightdatabase comparing it with every other trajectory to identify any loss of separation. If aconflict is found, the CP reports the 2 aircraft involved, including details such as start ofconflict and closest point of approach. This information is thus available to other toolsand to the GHMI for display to the controller. The conflict probe will also passinformation to the tools and GHMI when a conflict is cleared allowing the systemdisplays to be updated.

The flight path monitor (FPM) cheeks over 'radar' reported aircraft position againstthe stored 4-D trajectory for the aircraft. If the aircraft has deviated significantly in anydimension from the modelled 4-D trajectory the FPM raises a deviation alert for theGHMI to display to the controller. The deviation alert gives full information on thedeviation in all dimensions. However, in the PD/1 system not all information isdisplayed to the controller by the GHMI. The FPM also has the task of reporting whenan aircraft has passed a significant point on its trajectory. Such a point is identified tothe FPM by one of the system tools and the FPM alerts the tools when the subjectaircraft passes that point.

The ‘Problem solver, unlike the other PATS, that are not immediately visible to thecontroller, the Highly Interactive Problem Solver (HIPS) was one of the main GHMIinterfaces for the controller with system. HIPS is a sophisticated computer assistancetool which allows the controller to view several dimensions of the aircraft's proposedtrajectory to check that it is conflict free and to edit, negotiate and agree trajectoriesusing a horizontal, altitude or speed/ time view of the aircraft's predicted trajectory.



In addition to the HIPS, other components of the GHMI used by the controllers drewinformation from the tools. They included:

The augmented dynamic flight leg (ADFL) - which allowed controllers to highlight anaircraft's trajectory in the plan view display ('radar screen') and to accept it or proposechanges;

The conflict risk display (CRD) - which showed all potential losses of separationbetween aircraft in terms of how soon they could occur and what the minimumseparation would be;

The conflict zoom window (CZW) - which showed a forecast of the aircraft tracks fora particular conflict at the time of closest approach;

The horizontal and vertical assistance windows (HAW and VAW)- which showedaircraft positions

The communications list window (CLW): this prompted the tactical controller toissue 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 theexact working procedures to be handled in such a system and the correspondingcontroller strategies. As the exercise was experimental in nature, a decision was madenot to restrict the HMI to a particular working method, but to study the spontaneoususe 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 thecontroller.

The HMI comprised a basic set of PHARE advanced tools in a window managedenvironment, that could be configured to a particular scenario and to the Planning orTactical controller. The principle of 'Direct Object Manipulation' was applied to allscreen objects including aircraft trajectory manipulation. Interactive Track Data Blocks(TDB) provided information that made flight strips redundant. The display formatsdesign was guided by human factor principles and a task oriented logic. Colourapplication was task relevant and acceptable from a human visual perceptionstandpoint. The human machine interface provided consistent feedback on controlleractions and System State in order to increase system awareness. The applied 'minimalinformation' principle prevented display cluttering by removing information that is taskirrelevant for the moment, leaving the basic configuration at all times. All data wereaccessible by multiple means, and with minimal input actions required, and did notimpose a particular working method or strategy. The use of a re configurableconfiguration allowed a stepwise experimental design for the evaluation of theeffectiveness of a particular tool or HMI component, without confounding with otherlay-outs. All configurations are tested against a 'baseline' or 'reference system' that isas close to existing systems as possible. This allowed quantification of the respectivebenefits for traffic throughput, controller performance and workload.

The hardware on which the controller working positions were implemented includedlarge size colour displays with 2k x2k pixels. The input device was a three-buttonmouse



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)



• 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, wasexciting and well received.

No controller’s felt deprived of flight strips either paper or electronic, interactive datablocks were sufficient.

The colour-coding concept for indication of aircraft status was significantly accepted bythe 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 practicefor getting used to a three-button design.

The familiarisation and training package proved essential for introducing newconcepts. 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, indicatingthat with modern technologies sectors should be increased as compared with today.



Controllers tend to revert to their old controlling methods under highly loadingconditions. Training scenarios should emphasise the use of tools under theseconditions to prevent 'high traffic panic'

Age, computer literacy, learning ability and type of procedures being used to, werefactors in adapting to new concepts and procedures. Transitions are clearlyameliorated by the training package.

Some detailed features were not actually used spontaneously, and should either bediscarded or re-evaluated on their utility. More prototyping could have resolved thisissue.

The vertical and horizontal assistance windows in the 'old' technology based referencesystem proved of little value. The conflict risk display was relied on especially duringbusy traffic to allow earlier re planning options.

HAW and VAW, CRD were not highly used while HIPS, ADFL and TDB and CLW werealmost popular and very well received.

Appreciation of the ADFL was uniformly positive.

Controllers, who achieved high proficiency, seemed to favour the HIPS over theDynamic flight leg, while less proficient controllers favoured the Dynamic flight leg, amore traditional approach to planning.

The HIPS proved to be a powerful tool, that makes conflicts a pleasure to resolve, butrepresent a tool separated from the traffic window, which could reduce overall trafficawareness 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 facilitiesis depicted in Figure 28.

0

20

40

60

80

100

CZ

W

HA

W

CR

D

VA

W

AD

FL

CL

W

HIP

S

% 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



The PD1 trial could only be realised by excellent teamwork between many parties. Theconcept was highly advanced and represented a significant step away from the stateof the art controller working positions. So, it was open for criticism and suggestions asit concerned an experimental system, not a pre-operational system. Nevertheless,after working the system, controllers quickly adapted to and adopted many of thefeatures 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’. Thereason for that was that controllers have to work for extended periods, and highcontrasts etc. will induce visual fatigue. On first sight, the colours were notappreciated, but after working with them, acceptance was raised, demonstrating theimportance of actually working with such experimental systems.

A major result of the exercise was that the planner could handle almost all work. Thetactical controller, having little to do, started intervening with traffic and therefore withthe 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 usingsuch 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. Nomajor changes in roles for the controllers were anticipated for a near termimplementation. Controller working procedures, the working environment and theairspace structure were therefore quite similar to the current system.

The advanced mode comprises a strip-less environment with 4-D profile planning andconflict detection & resolution of planning conflicts. An arrival planning system (ArrivalManager) resolves planning conflicts by separating all arriving aircraft in space andtime. Advisories displayed to the controller are generated by the ground system inorder to support them in meeting the constraints of the Arrival Manager.

Deviations of aircraft from the planned trajectory as well as unsolved conflicts betweenplanned trajectories have to be resolved manually. The system supports the controllerin this process by measuring deviations and displaying them in time and space againstthe planned trajectory. The 4-D FMS equipped aircraft use datalink to negotiate andimplement airborne calculated trajectories that meet the constraints developed by theAM with respect to arrival sequence and schedule. For unequipped aircraft RT will givethe trajectory support.

Three guidance modes can be applied:

- Class A aircraft concerns 4-D FMS and datalink equipped aircraft with automaticimplementation of the trajectory.

- Class B aircraft concerns all aircraft that are guided via R/T, and for which theground system has support in the form of a conflict-free trajectory and theassociated advisories.

- Class M aircraft are guided manually via R/T without a valid trajectory, as appliedin the current systems.



Controllers monitor the flight progress of a Class A aircraft that will fly without R/Tcommunications other than ‘initial call’ and ‘frequency change’ when leaving thesector. In case of a problem, the controller can assume command via the R/T whichimplies that the negotiated contract is no longer valid. The status of the aircraftautomatically changes from Class A to manual mode as the system is updated aboutsuch tactical intervention by GHMI input. It was not possible to regain a Class A statusafter such intervention due to limitations in the PD2 equipment. The Tactical Controllertransmits the 4D-Guidance advisories produced by the ground system via R/T to theaircraft (Class B guidance).

The performance of the advanced system was compared with a reference system withmore standard type of facilities such as (radar data, flight plan data, paper flight strips,weather information, radio communication) and assistance from a simpler arrivalplanning system providing basic sequencing and scheduling.

• PHARE Advanced Tools

Trajectory Predictor (TP)- the TP generates the trajectory information for eachaircraft. In PD/2 only the arrival part of the trajectory was used, equivalent to about 30minutes flying time including the top of descent from cruise level until the ApproachGate (10 NM from runway threshold). All trajectories were generated using standardarrival routes (STARs).

Conflict Probe (CP)- the Conflict Probe compares the new trajectory of an aircraftentering the simulation with all trajectories already stored within the flight database ofthe ground system. Any violation of separation criteria like radar separation or wakevortex separation is identified and displayed in space and time.

Flight Path Monitor (FPM)- the Flight Path Monitor compares each radar position ofan aircraft against the 4-D position taken from the active trajectory stored in the groundsystem. Deviations in terms of distance in space and time are produced with thesurveillance update rate, for further processing by the supporting tools like the ArrivalManager, and for display to the controllers.

Negotiation Manager (NM) -the Negotiation Manager takes care of the air-groundexchange of information with respect to trajectories. It provides an interface betweenthe ground-based tool set and the 4-D FMS equipped aircraft equipped with an air-ground datalink.

Arrival Manager (AM)-the Arrival Manager is the core tool in the PD/2 environment. Itoverviews multiple sectors in order to provide optimised scheduling and sequencingadvisories for all arriving aircraft. Basic AM functionality is in use in today systems;based on arrival time prediction, for instance COMPAS. That basic functionality isextended with trajectory information, generated by either airborne or ground basedtrajectory predictor systems. The Arrival manager has four main components: theArrival Time Predictor, Sequencer, 4-D Descent Manager and the Approach ProblemSolver.



Arrival Time Predictor

The arrival time predictor gathers all necessary information like airspace data and flightplan data, to prepare a constraint list. This constraint list is sent to the TP tool forground-based calculation of a preferred trajectory together with the earliest and latestpossible arrival time at the Approach Gate. If alternative routes are possible, like theWest Approaches in PD/2, a trajectory with the set of estimated arrival times for thealternative routes is stored. Each entry of a new inbound flight activates the ArrivalTime Predictor Module.

Sequencer

The sequencer tool provides the sequencing and scheduling functionality of the ArrivalManager. In the first step the preferred times at the Approach Gate are checkedagainst separation violations in time. If the CP reports no conflict the aircraft isscheduled for the preferred time. If the aircraft is 4-D FMS equipped, the NM tool isactivated to initiate a negotiation via datalink. The ground constraints list is uplinkedand the aircraft downlinks an airborne trajectory. This trajectory is checked again bythe CP against all other trajectories already planned and agreed. If no problems aredetected the airborne trajectory replaces the one calculated by the TP.

If aircraft are in conflict with their arrival times a branch and bound algorithm isactivated to sequence according to predetermined rules like first come first serve,close gaps in the sequence, optimise wake vortex categories. The arrival times arevaried within the earliest and latest time limits in order to optimise the sequence. Ifalternative routes are allowed, which even may belong to different runways, theseroutes will be checked for a better solution. This leads to a set of new constraints andthe generation of a new trajectory by the TP fulfilling the new constraint for arrivaltimes and possibly for a new runway allocation. If the CP tool finds no conflicts theaircraft are scheduled for that target time.

At the border of the Extended TMA an equipped aircraft will go through the followingsequence of air-ground negotiation steps in order to get a contract to implement thetrajectory automatically:

- Uplink of Constraints

A message is uplinked containing the route identifier and time constraints at thegate. This requires that the AM Manager has completed the 4-D planning of thisaircraft, on the basis of information available on the ground. This can be a groundbased TP trajectory, or a trajectory downlinked earlier by the aircraft in a previoussector.

- Downlink of Trajectory

The aircraft processes the constraints and downlinks a trajectory. If the aircraftcannot meet the constraints it says so. This aircraft will then be guided via RadioTelephony (R/T) as an unequipped aircraft.

Approach Problem Solver- in case of conflicts found by the CP the AM varies altitudeand time constraints in order to obtain a conflict free trajectory. This capability waslimited to arrivals trajectories.

If no solution is found the scheduled time in the arrival sequence is maintained but thetrajectory is displayed as being ‘in conflict’ to the controllers. It is now the task of thecontrollers to vector the aircraft from its route to avoid the predicted conflict area.



4-D Descent Manager- the task of the 4-D Descent Manager module is to implementeach scheduled trajectory. The trajectory is translated into advisories that can serve ascontrol commands for R/T. Advisories are generated for turns, descents, descentrates, and speeds. In addition the position and time of application is produced. Thesedata are transferred to the GHMI before expected execution time in order to allow anadvanced indication to the controllers. Deviation messages given regularly by theFlight Path Monitor are used by the 4-D Descent Manager to decide whether theguidance 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 approachcontrol. It consists of a multi-window environment that can be configured to fit therespective controller roles, preferences etc. The main elements available on eachworking position were the Plan View Display for the Radar information together with aConflict Risk Display (CRD) and an Arrival Management Display for the planningcontrollers on a separate screen. Only for the ACC controllers additional SectorInbound List windows were shown on the PVD in order to provide flight planinformation in advance for selectable entry and exit fixes. In the ACC-position anadditional Vertical View Display (VVD) window provided a vertical view of the trafficover fixes where holding patterns are normally located. However, note that holdingpatterns were planned not to be used in the PD/2 simulations.

The plan view display

The PVD depicts the airspace together with the labelled radar targets. A radar toolboxwindow allows the controller to select the centre, scale, number of history dotsdisplayed with the radar targets as well as the airspace elements. Also a labelpositioning method can be selected. The controllers can (de-) select the Conflict RiskDisplay (CRD) that pops up every time a conflict is detected. This window indicateseach conflict as a small red box, indicating the time ahead of a conflict (in minutes) andthe minimum distance at conflict time (in nautical miles). The call signs of theconflicting aircraft are listed. By clicking on the red box the controller can highlight thelabels of the associated aircraft at both the PVD and AMD. No short-term conflict alertwas included in the PD/2 system.

Aircraft Label

The main interaction mechanism is label oriented. A controller selects a label bymoving the mouse cursor over the label. Selection is indicated automatically by abackground 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, isin a transfer status, or is under own control. Transfer could be initiated by clicking thetransfer field in the upper left corner of each label. An alternative method is to inputflight 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 themouse, 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 alabel 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 movingthe mouse over the callsign indicator of an aircraft.



The target shape shows the equipment of an aircraft. A square indicates 4-Dequipment (datalink and 4-D FMS), a circle indicates non-4-D equipped aircraft. A 4-Daircraft with a cleared contract (Class A aircraft) is shown as a filled square. Class Baircraft (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 theArrival Manager are displayed in orange in a third label line for advised altitude/flightlevel, airspeed, heading, rate of descent, and are preceded by a tick marker field thatcan be clicked on by the controller if the R/T command is activated. In that case thethird line shows the last cleared FL if the aircraft has not reached it. The orangeadvisories disappear automatically when the time of application is reached.

Trajectory representation

Figure 29 shows the PVD representation with selected label and complete trajectory on theexample of SAS171 arriving on a northern route via the metering fix Gedern to RWY 25Ron the left bottom of the figure.

Figure 29: Trajectory Presentation at the PVD

selected label

SAS 171 B737 :

last cleared FL : FL 125

current FL : FL 210

speed : 360 kts

heading : 182

descent

FL 100 -> FL 80

descent

FL 80 -> FL 70

descent

FL 70 -> 3000 ft

deceleration

300 kts -> 250 kts

deceleration

250 kts -> 220 kts

Metering Fix

GEDERN (GED)

SAS171 B737 EDDF

210 36 182 -1820



The trajectory information on the PVD is graphically represented as a blue line alongthe whole route for each aircraft. The planned position of an aircraft is marked as ablue cross at the trajectory line. Another option is to visualise the future planned pathsas 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 trajectoryindicate significant positions where the aircraft status will undergo changes. Examplesare start/end of descent or speed changes together with the previous and new targetvalues written at the markers in two lines. In addition, for class B aircraft yellowmarkers show where to apply the necessary advisories. An open square is used for aheading, a tilt cross for altitude and a cross for speed advisory positions. Thesemarkers 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 displaylayout for the Approach Controllers. Here the time for the Approach Gate is thereference time. For ACC West the time over metering fix RUD is the reference time.

actual time: 10:15

label colour yellow:

arrival via PSA label colour blue:

arrival via GED

actual time at GATE: 10:15

delay pointer

4-D / class A

heavy

3-D / class B

planning time SAB513: 10:28:20

actual time: 10:15

aircraft planned for runway 25L aircraft planned for runway 25R

label colour yellow:arrival via PSA label colour blue:

arrival via GED

label colour green:arrival via RUD

actual time at GATE: 10:15

delay pointer



The input buttons shown at the right allow interactions with the Arrival Manager aboutsignificant 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/2in 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 arrivalroutes (blue = north, yellow = south, green = west).

Aside of each label frame the angle of the 'delay pointer' shows the deviation in timeas measured by the FPM. An upward (downward) pointer indicates whether aircraftare delayed, whereas a horizontal tail line indicates no delay

• Trials Facility

The PD/2 trials were conducted on the Air Traffic Management and OperationsSimulator ATMOS of DLR. This section provides a brief overview of the facility and itsconfiguration for the trials. The picture below gives an impression of the ATMOSenvironment and the controller working positions.

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

Observer

Feeder

ACCPlanner

Pickup



• Results

The use of the mouse was again significantly accepted as a suitable device forinteracting with radar labels and pop-up menus, but sometimes an overloadedsimulation system caused slow response times making it difficult to select specificelements.

Controllers generally agreed with the screen layout and size, as well with thereadability of text, and there were no problems with the abbreviations used. Also theconcept of colour coding of the labels, for indication of the control status, was regardedas being highly comprehensible and useful. Together with the indication of the actualmode of guidance (class A, class B, or manually guided) which was given by theaircraft symbol, these were significantly well accepted by the controllers.

The options of changing the displayed length of the trajectory prediction and changingthe track history which enabled controllers to have a look on the past and the future ofany aircraft’s flight path, were highly appreciated.

Analysis of controller roles revealed a re-distribution of workload between tacticalcontroller positions. A decrease of workload was found for the Approach Pickupcontroller position, which normally represents the position with the relatively highestworkload.

The effect of relieving the controllers from transferring ATC instructions was marked.So the addition of more equipped aircraft would increasingly benefit the overallworkload levels.

One particular lesson learnt was that advanced designs clearly challenge the capabilityof many simulation platforms. In PD2, some functionality had to be adapted/ limited inorder 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 havemessed up the traffic scenarios. The results of the study are therefore obtained in amore 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 illustratedbelow.



The percentage of participating controllers that frequently used the respective facilitiesis depicted in the next figure. Note that the use of the VVD is artificially restricted bythe PD2 scenario, as no holding patterns were to be present due to advancedplanning. Alternative scenarios would likely result in more extended use.

0

10

20

30

40

50

60

70

CRD VVD AMD SIL

% of use

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



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

• Discussion

The PD2 trial illustrated that a more automatic world could provide quite consistentand efficient traffic patterns. However, no real life disturbances were simulated due torestrictions in the simulation environment. However, it led to a revival of discussion onwhat kind of strategy would be best for the future. Computing power is really requiredfor GHMI’s 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 toolsarrangements. Suppose that an aircraft wants a change in route. It downlinks thetrajectory to the ground and the controller is notified. Now the controller has to decideand switch on the conflict probe to see if the request would pose a problem. Analternative would be to directly load the request into the conflict probe. No problemdetected? Than an approval is immediately sent to the aircraft. Whatever appeal sucha strategy may have from a technical point of view, it implies that the controller is keptout of the loop. No behavioural data on the consequences of such a working methodfor the level of traffic awareness of the controller is available yet. Clearly, moreresearch on the issue is required when pursuing such a configuration.



5.3.3. The multi-sector Gate to Gate GHMI’s (PD-3)

• Organisations Overview

PD/3 is a real-time simulation comprising two organisations; a Baseline and anAdvanced Organisation. The baseline organisation is a reference close to the today'soperational situation. The Advanced Organisation is characterised by the followingconcepts:

- 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 periodfrom 2005 to 2015, when the traffic mix will progressively comprise a population of 4Dequipped 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 environmentwithin the core area of Europe, with potential for a significant capacity increase overthat of the present air traffic system while benefiting airline operators with moreeconomical flights.

Extra capacity will be found with the introduction of new flight management andprecision navigation systems, data-link communication, multi-layer planningtechniques, and advanced ATC tools to improve air traffic management. Theintegration of these developments into a single air- ground entity, while retaining thedecisive roles of Air Traffic Controllers and Pilots is a prime objective of the PD/3Advanced Organisation.

Air traffic congestion does not occur evenly throughout a system, but appears asisolated complexity zones, in different sectors at different times. These areas ofcomplex 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 accurateprojection of flight trajectories and permit forward, multi-layered planning.Communication congestion will be addressed by the introduction of two-way data-linkcommunication permitting the silent exchange of large amounts of informationnecessary within the proposed environment.

The restructuring of ATC planning and the addition of an extra multi-sector Planninglayer could improve present Air Traffic Management. Air Traffic Flow Managementprovides a strategic planning service several hours before the aircraft enters the airtraffic control sector, where the tactical controllers are operating only a few minutesahead of the aircraft conflicts. The role of a Multi Sector Planner will be to offermedium-level strategy rather than tactical solutions to overcome traffic complexity.Aircraft trajectories will be planned over several sectors. The aim is to reduce theworkload of sector controllers and provide more optimal trajectories for suitablyequipped aircraft.



The roles of the sector controllers will be changed to allow anticipated planning by thesector planning controller while assisting the sector tactical controller and providingeach controller with complementary tasks consistent with the planning time horizon.The three layers of planning and control shall provide for adequate control of the trafficsituation 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 ofdata and to improve the aircraft role in the flight planning process. An important featureof the Advanced Organisation selected for evaluating the PD/3 concept is that the AirTraffic Controller and Pilot retain central roles. The Human Centred Approach (HCA) isemphasised and the appropriate balance between the system processes and humaninterest is retained.

The Advanced Organisation described in the following pages is based on arationalisation of previous concepts featuring the Human Centred Approach and alevel of more strategy traffic organisation. The organisation selected involves the MSPin partial de-conflicting while considering strategic objectives.

Several considerations and limitations were necessary when selecting the AdvancedOrganisation. It was recognised that the proposed environment required theinvestment of airline operating companies in costly new equipment. The AdvancedOrganisation must therefore provide a measurable cost benefit for equipped aircraft tofund this investment, without increasing the system handling demands for nonequipped aircraft.

Limitations included a shortage of time for educating controllers in working methodsvery different from those currently in use and experimental constraints limiting thenumber of different organisations that could be evaluated.

The selected Advanced Organisation presents a scenario where the main concept canbe evaluated, however various options have been identified to enhance theexperimental process and provide extra clarification. These include variations in themix of data-link equipped aircraft, changes in the controllers roles, different airspaceconfigurations and testing of the impact of Arrival Management on planningprocedures.

Further options were considered that might warrant future investigation. Althoughfundamental airspace, route and sectorisation changes are anticipated followingimplementation of a new planning structure the specific changes are not yet defined.Upper flight level allocation may also change with the introduction of Reduced VerticalSeparation Minima (RVSM), however RVSM implementation is still being considered.The Advanced Organisation therefore utilises existing airspace, route structures andflight 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/3addressed the simulation of an air traffic control environment with demonstratedbenefits for aircraft, with significant airspace capacity gains for the period 2005 -2015.



• 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 theintention of evaluating potential capacity and economy improvements from trafficorganisation, early planning and anticipated conflict resolution (deconflicting) throughair/ground negotiation over a larger area and for larger ‘look-ahead’ times. Theconcept is aiming at introducing the redistribution of workload from tactical controller toboth 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-sectorplanning down to the tactical phase of executive control, a continuously refined andupdated air-ground contract negotiation process offers the advantages of precisetrajectory prediction and thus the confidence in planning trajectories, combined withthe flexibility of an adaptive system. The concept is based on improved knowledge viathe intensive exchange of data between individual operating airborne and ground-based 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 situationcomplexity can be reached.

Some of the conditions, considered as essential in order to be able to make theconcept successful, are:

- 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 statusand

- The associated benefits to 4D controlled flights.

- A high capacity and flexible ATN system.

-

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 controlprocess, the management of trajectories in space and in time should remaincompatible with ATCO skill and know-how so as to allow him to exercise hisresponsibility and his key role in the decision making process.

The organisation of the trajectories in space and time should allow the controller tobuild and maintain a relevant representation and control of the traffic situation, which isrequired to perform his task at his level of intervention.



• 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 minutesahead 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-sectorstrategy 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 implementedby the sectors either linked directly to equipped aircraft or to be implemented by TCsector for non-equipped aircraft.

- Balancing the sector's workload in redistributing traffic between sectors whenappropriate;

- 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 preferredtrajectories.

Note: it is the MSP's task, if appropriate, to overrule LOAs according to the analysis ofthe traffic situation. It is expected from the MSP actions to keep to a minimum thetrajectory penalties imposed by LOAS. This is assumed to be achievable up to acertain complexity threshold. Beyond this, the action of the MSP will be to focus mainlyon re-organising difficult traffic sequences and balancing the workload betweensectors as appropriate.

- To intensively use the PRNAV aircraft capability with the aim of favouring theelaboration of parallel tracks and direct routes.

- To replan 3D aircraft in such a way that the TC will easily transmit verbally to theaircraft the MSP modifications. The changes should result in a as stable aspossible situation reducing the need for vectoring and speed control. The actionsfor 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 todemonstrate that a more natural way to control 3D aircraft than the pseudo 4D way isreducing workload of the TC and therefore is beneficial to 4D aircraft. The equippedaircraft are easy to reach by data link and it has to be prevented that equipped aircraftare manoeuvred around 3D aircraft. In that case it would result in an unintentionalbenefit for non-equipped aircraft (lesson learnt from PD/1).



• Co-operative approach

As shown, in the PD/1 results, there is a need to improve the role of the controllerteam and work at sector level. The solutions, investigated in PD/3, are to integratetools 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 withthe complexity and the variability of the control situations.

- Preserving the controller interest for his job: his creativity to face a new trafficsituation and to elaborate relevant solutions. The objective is to avoid to move hisactivity to a supervision role which will induce loss of skill, poor traffic awarenessand inability to cope with unpredicted events.

- Preserving the teamwork by introducing a common representation of the problemsituation and computer assistance for an analysis of the traffic situation and amemorisation of identified problems, and the preparation and implementation ofsolutions.

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 ground-based ATC systems and to rely on the integration of ground-based ATC systems ofdifferent 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 arederived from the use of data communication for:

- Information exchange

- Advanced control procedures

The exchange of information gives the background information for the accurate andconsistent prediction capability on the ground and in the air. Advanced data-linkinformation exchange processes inform the ground on short and medium-term aircraftflight intentions and informs the aircraft on e.g. more accurate meteorologicalconditions and about short and medium-term flight planning constraints.

The most advanced process to control air traffic, is 4D control and negotiation. Anessential feature of this Advanced Organisation is to apply a fully integrated process ofair-ground and ground- ground co-ordinated dialogues via data-link, leading totrajectory ‘contracts’. The high accuracy of 4D prediction and 4D guidance supportsenhanced computer assistance and working methods which will lead to increasedcapacity of the ATM system and enables the ATCO team to handle more aircraftsimultaneously.

At the same time, consistency and compatibility with different levels of equipment inmixed traffic situations is reached by full compliance of 4D guidance and control withshort-term and tactical control processes. Unequipped aircraft shall be controlled bymore tactical and more traditional procedures, using RT. lt is a requirement of theAdvanced Organisation to offer the ATCO a GHMI capability which supports suchcompatibility. Look and feel behaviour of the GHMI in servicing aircraft either via 4Dtrajectory negotiation and/ or e.g. via RT, should be compatible and combined withefficient updating of the SPL.



Ground-Ground communications philosophy in the Advanced Organisation of PD/3

Advanced use of ground-ground communication and, related to this, an integratedATM concept for planning and control is definitely required as complementary addedfunctionality to air-ground integration. Exchange of surveillance and system flight plandata 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 centreboundaries 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 teammembers, 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 sametime ATM systems of different centres should be able to work independently of eachother. This independence is required for reasons of robustness, fallback options andmanagement requirements. Different ground systems should be able to workindependent, to be able to rely on own process and task scheduling, on the processingof 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 andown consistency checks.

The required independence of ground systems is reached, while achieving at the sametime a maximum level of ground-ground integration, applying weak coupling betweenground systems, combined with a frequent exchange of surveillance and flight planstatus information.



• Results

The specification of a GHMI for such a complex system as pursued in PD3 proved tobe quite an endeavour. Nevertheless, the GHMI design team produced an extensivespecification under extreme high time pressure. However, implementation proved tobe as difficult as the specification. As a consequence, the simulations had to be limitedto fit the local capabilities of simulation systems. A similar problem as encounteredduring PD2. So, only two sites (CENA, NLR) realised a simulation, although with quitedifferent characteristics. It has to be noted however, that these results were achievedin close collaboration with EEC.

The general impression of the simulations is that the results of the earlier work in PD1and PD2 are essentially replicated. So, controllers acceptance will increase as afunction of exposure to new designs and an opportunity to train and work with newoptions. It is of interest that controllers proved to be able to be quite flexible in adaptingto some, essentially different features as compared to their day to day work. Thespecific simulations will be discussed in some detail in the next sections.

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 GHMIgroup (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 inFigure 33. Therefore, some adaptations had to be made in order to cope with itsspecific layout characteristics. The average distance between the main screen andATCO’s eyes necessitated a larger font size that in turn created problems with theavailable display space. Fortunately, the ancillary screen (21 inches) of this CWPcould 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)



6.1. EXAMPLES OF GHMI IMPLEMENTATIONS

Figure 34 En-Route GHMI (main screen)

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 theAdvanced Configuration is shown in Figure 34 and Figure 35. The main screendisplays the Radar Image and Activity Predictor Display and the ancillaryscreen displays the Message In/Out Windows and the Profile Window. Theconfiguration was made after having collected ATCO’s inputs and feedback during thePilot Phase.



6.1.1. The main screen

• Radar Image:

A major part of the main screen is devoted to the Radar Image: it displays

- 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, todisplay route.

- Main Menu allowing to change flight state (ASSUME, TRANSFER, etc ...) is in factoffered in any window where the callsign of an aircraft is displayed.

This Radar Image is modal: i.e. filtering modes are either Problem oriented (selectablewith Activity Predictor Display) or aircraft oriented (selectable through the TrajectoryEditor and Problem Solving facility) are offered.

Contrarily to what PD/1 proposed, the Highly Interactive Problem Solver facilities werenow integrated in order to decrease the number of separated windows. The lateralwindow of the HIPS was directly integrated in the main Radar Image and a Time menureplaced the dedicated Speed Window, also directly available in the main Radar Imageand in the Profile Window.

• Activity Predictor Display

The APD provides a time axis; on the left side, ATC problems to be solved by theATCOs are posted to the ultimate time of resolution; on the right side, advisory (ATCinstruction) 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-Aheadfacilities were implemented.

• Additional windows

Radar toolbox and Clock window complete the main screen allowing to configure radarimage (map, space layers)

6.1.2. The ancillary screen

• Message In / Out windows

The Message Out Window collects the request for coordination issued by neighbouringcontrollers or important system messages. The Message In Window is a log of sentmessages.

• Profile Window

The Trajectory Editor and Problem Solving facility once activated displayed the verticalprofile of the aircraft in a dedicated window: the Profile Window. Interaction zones aredisplayed by the Problem Solver; the controller may draw a new working trajectorycombining vertical constraint (in this window), lateral constraints (in the Radar Image)and time constraint via Time Menu facility.



6.2. THE 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 theDeparture Manager Display;

As for En-Route and ETMA position, Message In/Out Windows and Profile Windowwere set on the ancillary screen (as shown by Figure 35).



6.2.1. The main screen

• Radar Image:

A major part of the main screen is devoted to Radar Image: it displays the currentposition 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, todisplay 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 isoffered (selectable through the Trajectory Editor and Problem Solving facility).

Also, the Highly Interactive Problem Solver facilities were integrated in order todecrease 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 thetwo runways available at Roissy / CDG (« 27 » and « 28 »). On each axis arepresented 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 barmarks current time.

This tools allow to organise take-off sequences, pick-up additional flight planinformation, CFMU time slot information, delays and all information related tosequence management.

• Additional windows

Radar toolbox and Clock window complete the main screen allowing to configure radarimage (map, space layers)

6.2.2. The ancillary screen

• Message In / Out windows

The Message Out Window collects the request for co-ordination issued byneighbouring controllers or important system messages. The Message In Window is alog of sent messages.

• Profile Window

The Trajectory Editor and Problem Solving facility once activated displayed the verticalprofile of the aircraft in a dedicated window: the Profile Window. Interaction zones aredisplayed by the Problem Solver; the controller may draw a new working trajectorycombining vertical constraint (in this window), lateral constraints (in the Radar Image)and time constraint via Time Menu facility.



6.3. INTEGRATION OF PHARE ADVANCED TOOLS

The overall efficiency of the PD/3 concepts depends highly on the controller havingappropriate computer assistance tools. PD/3, on a technical and organisational point ofview, set a very high level of complexity compared to previous PHARE Demonstrationssince, no less than 9 different PHARE Advanced Tools (PATs) designed by 5 differentATM 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 theTrajectory Predictor, the Flight Path Monitor, the Conflict Probe, and the ProblemSolver. Brand new tools were created (Departure Manager) or adapted (NegotiationManager1, Co-operative Tools) for this experiment.

Two tools (Arrival Manager and Tactical Load Smoother) were not integrated becausethey were not part of the CENA PD/3 experiment (no ARRival position or MSPposition).

6.3.1. Trajectory Predictor (TP)

The role of the Trajectory Predictor is to predict the trajectory of an aircraft taking inaccount all known information. Compared to tools already in use in ACC, this new oneis far more accurate, using a database of aircraft performance characteristics andcapable to be enriched by downlinked aircraft trajectory. For sure, it is of major help fornon equipped aircraft since all assistance provided to the controller will depend on itsoutcome and it is a fundamental tool because a lot of the overall behaviour of thesystem rely on it.

The PHARE version of this tool was not integrated on the CENA’s platformunfortunately; the PHARE version, faced some problems during very late integrationphases jeopardising the demonstration; as a fallback solution, it was decided locally touse CENA’s STRANGE version. Its algorithm was upgraded in order to make itcompliant 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 Airborne part: the traffic generator used a specific one while the Multi Cockpit Simulatorand 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 detectpossible conflicts between 2 departing aircraft. This tool was in fact used internally byother tools as the Departure Manager in order to determine automatically the best SIDtrajectory, and as the Negotiation Manager to evaluate if a proposed trajectory, in caseof a co-ordination, was conflict free or not.

For En-Route and ETMA especially, Medium Term Conflict Detection was in factdevoted to Co-operative Tools; this new tool allows to have a better view of problem atstake 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.



6.3.3. Flight Path Monitor (FPM)

This tools checks every new aircraft position against the stored 4D trajectory; if asignificant deviation is detected in any dimension, the FPM raises a deviation alertdisplayed on the GHMI.

6.3.4. Negotiation Manager (NM)

The role of this tool is to manage communications between the different actors sharingthe same information, mainly trajectory of an aircraft: it receives either Pilot Request orATC sets of constraints and decide, using underlying tools such as CP and TP, towarn the right people in the right manner. This tool encompasses a threshold logiclimiting 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 assessdifferent solutions for solving a conflict: this tools gives the controller an immediatefeedback (yellow or red zone appearing directly on the radar image and the verticalprofile 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 thedesire to limit switch of use between the radar image and another tool especially forthe Tactical controller; thus, the HIPS was directly integrated in the main radar imageimposing this image to be modal while in HIPS operation. This was a major differencewith PD/1 GHMI where lateral modification via the HIPS took place in a dedicatedwindow.

The Highly Interactive Problem Solver was, as in PD/1, coupled very tightly with theGHMI 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 departuresequencing: CFMU slot constraint, operational rules which imposes delay between 2take-off (because of wake vortex) and separation rules during climbing phases; itpursues the objectives to limit the delay between Scheduled Time of Departure andEstimated then Realised Time of Departure, and proposes to the controllers asequence 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 ATCand companies.



6.3.7. Co-operative tools (CT)

These tools encompass different functionality: at first, predicted trajectory issued fromTP is reconsidered in order to match controller perception; at second, «problemdetection» is processed aiming at gathering conflicts in Significant Traffic Unit: theseproblems are posted along the time axis of the Activity Predictor Display according tothe priority of solving.

Subsequent functionality allow the controller to filter the radar image focusing on aspecific problem and performing look-ahead for the set of aircraft involved in theproblem.

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 theETMA position because the quality of problem detection was too poor.

6.4. MAIN LESSONS LEARNT

The principle of computer assistance was well received by the controller: especially theintegration of tools like Co-operative Tools and Highly Interactive Problem Solver onthe En-Route Planning Controller position offered a powerful environment.

On the Departure position, the first acquaintance of controllers with a DepartureManager created great interest. Some controllers stated they intend to ask for an in-depth evaluation of this tool in a more realistic and short-term ATC environment.

Recommendations extracted from CENA PD/3 experiment report state that, futureATM projects utilising (part of) PHARE concepts should:

- explore ways to simplify Air-Ground Trajectory Negotiation and propose at sectorlevel, procedures which comply with time pressure (it could be derived fromCPDLC or Formalised Clearance);

- especially explore ways to simplify trajectory edition; TEPS facilities often provokean increase of ATCO workload;

- do everything to obtain responses time as short as possible, a reliable overallsystem as well as logical and clear responses of the system;

- limit automation to what can be without any doubt trusted by controller and provideco-operative system functions allowing the controller to remain the master of thesystem;

- benefit from the techniques used in the preparation of this experiment to teachcontroller trainees ; the use of a standalone HMI system for practice appearedworthwhile ; the directive method utilized to teach both working method and HMIwas well accepted and allows to teach very futuristic concepts with a good level ofmastering at the end.



6.5. GHMI DISPLAYS AND INTERACTIONS

On the one hand, a majority of controllers reported a positive feeling about the codingof many HMI objects when considered independently. For instance, a significantmajority of controllers thought that coding of radar labels were quite efficient (logic andcomprehensible) and allowed status of each aircraft to be clearly identified. However acommon 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 priorityinformation was managed as insufficient and not obvious enough (common criticismwas that some factors like SIL, labels overlapping and filtered views might hidesometimes important radar image information).

The specific STCA presentation was rejected by a majority of controllers. They justifiedit 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 (19inches) led to significant positive answers (controllers particularly appreciatedpresentation of the Profile Window in the second screen).Interacting with the systemthrough the mouse has been generally considered as a suitable solution. However ageneral 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 reallyuneasy) and strongly wished improvements on it or an introduction of parallel inputdevices such as a mini-keyboard.

6.5.1. TEPS/TST

Comments on the TEPS in DISPLAY MODE indicated that controllers agreed itallowed a quick way to consult a specific trajectory or compare several ones. In otherrespects, a controller reminded that he would have appreciated the possibility todisplay several trajectories while editing one.

A significant majority of controllers reported that they frequently used the TEPS inEDIT MODE as PC. Comments indicated that they performed as much as possibletheir planning activities and were de facto obliged to use the TEPS. It was logical tostate an opposite trend for the TC position since the controllers instructions givenduring the training specified that TEPS in EDIT MODE was much more devoted toplanning activities.

Results were similar when controllers were asked if they used frequently the ProfileWindow. Trend was negative when considering TC position whereas a significantmajority of controllers reported they frequently used the Profile Window in PC position.

Opinions regarding the helpfulness of TEPS for avoiding conflicts diverged dependingon the sector. Indeed, all the controllers from En-Route sector reported that theyagreed or slightly agreed with this statement while TEPS was not seen in this light by amajority of controllers from ETMA and Departure sectors. Negative answers havebeen 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.



En-Route controllers clearly expressed that TEPS and TST facilities provided goodconditions to well manage planning activities with non equipped aircraft and de-complexify the traffic. However the trend was opposite for ETMA controllers. Answersfrom Departure controllers were quite mixed. Comments indicated that positivefeelings were mainly due to the possibility of resolving conflicts in advance whilenegative feelings were due to the lack of co-operation PC/TC which hampered theefficiency of planning actions. In others respects, a significant majority of controllersraised that TEPS facilities are useful in PC/TC co-operation only when supported byoral communication.

Moreover, both PC and TC sometimes met some difficulties to build a clear awarenessof each trajectory status. The following questions did not always give rise to a quickanswer. Is it a conflict free trajectory? Is it a foreseen trajectory? Has somethingspecific been changed by the PC? Is someone currently working on the trajectory ofthis aircraft or intending too?

Opinions were quite mixed regarding the way TEPS and TST helped controllers tomanage data-link exchanges with equipped aircraft. The excessive time demand(validation step or crew reaction) was, according to the controllers, the main factor tobe improved. However, a significant majority of controllers reported that, in thiscontext, their workload due to VHF communication was reduced.

Considering response time of the Trajectory Edition, it appears that ATCO averagetime 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 7second (minimum value is equal to 5s and maximum value is equal to 9s) even thoughHuman Factors data generally recommend that a delay for getting an answer from asystem should not exceed 2s.

Considering trajectory negotiation the use of TEPS greatly benefited from the overallconvenient 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 telephonecould be reduced by TEPS and TST facilities. It can be noticed that all the En-Routecontrollers positively answered to this question. However, opinions were quite mixedregarding the way the co-ordination with entry and exit sectors could be managedthrough the TEPS and TST facilities. Comments indicated that the principle ofexchanging a trajectory can be full of promises but some incertitude - Is someonecurrently working on this aircraft? Has a something been changed on this trajectory bysomeone else? Can this facility substitute the telephone in case of emergency?



6.5.2. MIW/MOW

In Baseline organisation, a majority of controllers (statistically significant for TC andtrend for the PC) reported that they did not frequently used the MIW/MOW. Negativeresponses were all statistically significant (PC and TC positions) when considering theAdvanced organisations. Whatever the organisation, a majority of them rejected thestatement that the MIW/MOW were helpful for optimising co-ordination. Commoncomments raised that they were not enough alerted by an in-coming message andthey did not really integrate the MIW/MOW in their visual checking. Some controllersadded that just a sound signal would have correctly drawn their attention on thosewindows. The positioning of the ancillary screen could be a factor in these results asscanning is more complicated.

Other comments indicated that messages were not enough explicit and often forcedthem to use the phone. Improvements of the MIW/MOW would be desirable for all theorganisations.

6.5.3. CRD (used only in the Baseline environment)

A majority of controllers reported that they did not use the CRD frequently in TCposition. 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 butclearly criticised the fact that conflicts were most of the time non pertinent or affectedanother sector. They consequently estimated that the CRD was not useful for reducingtheir workload (statistically significant result). A majority of them (trend) justified it bythe fact that information displayed in the CRD was not helpful for avoiding conflicts.Associated comments indicated that the display was quickly cluttered by obsoleteconflicts that could not be removed from it and thus prevented them from efficientlycheck the CRD content.

All the controllers thought that improvement in the CRD would be desirable for all theorganisations.

6.5.4. SIL

A majority of controllers stated (trend for TC and not significant result for PC) they didnot 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 conflictin sector entry. However a significant majority of controllers reported that SIL was nothighly relevant for their work and they all stated that improvement as follow couldchange their point of view: when presented on radar display, SIL should not in any wayhide other information (e.g. radar labels) and present complete information on requestlike route details (the destination notably); when automatic removal event occurs, itshould come with explicit fact that the associated aircraft has been fully integrated bythe controller.

2 Departure positions were not provided with SIL



6.5.5. Advisories labels in the APD3

Advisory labels in the APD aimed at helping TC to organise his control activity and togive prepared instructions just in time. Feeling about this depended on the sector.Indeed negative and positive opinions were balanced in En-route sector whereas allthe ETMA controllers gave a negative one.

A common criticism was that advisories messages were often without operationalsense (incorrect or concerning another sector) and it led the controllers to mistrustthose messages. Hence, a significant majority of them wished improvements in theadvisory labels information.

6.5.6. Departure Manager

A positive issue can be raised regarding overall information that was provided by theDM display. DEP PC appreciated the clear and synthetic view of pre-departure trafficpattern: the overall ground sequence on each runway, the occupation balancebetween both runways and the precise configuration of aircraft that were about to take-off (this last one was also appreciated by DEP TC).

Animation features implemented in order to produce a smooth feedback of what thesystem or the ATCO did, appeared as a useful tool in order to give a better awarenessof what happened and especially, discovery of error. If tactfully implemented, theyreally improve exchange between Man and Machine.

3 Departure positions were not provided with APD




PHARE GHMI Project, Final Report The NLR PD/3 GHMI


7. THE NLR/ PD3 GROUND HUMAN-MACHINE INTERFACE

7.1. AIRSPACE AND OVERVIEW GHMI’S

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 thesesectors there are roles of tactical and/or planning, depending on the sector definition.

The following sector{xe "sector"} configurations and the associated GHMI’s have beenused:

- En-Route(ER) Sectors:

Maastricht Brussels West Planner and Tactical 2 GHMIsACCAmsterdam ACC-South Planner and Tactical 2 GHMIsAmsterdam RIVER Stack Tactical 1 GHMI

ARRAmsterdam TMA Planner and 2 Tacticals 3 GHMIs

- Feeder Sectors:

En-Route (ER)Maastricht South 1 GHMIMaastricht Delta 1 GHMIACC

Amsterdam ACC-North/East 1 GHMIAmsterdam ACC-North/West 1 GHMIBrussels ACC 1 GHMIAmsterdam ARTIP Stack 1 GHMIAmsterdam SUGOL Stack 1 GHMI

The NLR PD/3 GHMI contained, in contrast with the CENA configurations, separategraphical interfaces (windows) for the Highly Interactive Problem Solver. All sector{xe"sector"} configurations have the HIPS interface, but only the TMA sectors have theAMD.

The airspace is defined as the grouping of sector{xe "sector"}s that are controlled bythose air traffic controllers that are being measured for the experiment (even though inthe PD/3CT no measurements were made in the end). These sector{xe "sector"}scomprise the Schiphol TMA, the Amsterdam Radar South ACC sector and theMaastricht Brussels West sector.

Error! Objects cannot be created from editing field codes.



7.2. EXAMPLES OF GHMI IMPLEMENTATIONS

7.2.1. ACC and TMA working positions

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

The NLR PD/3 GHMI PHARE GHMI Project, Final Report


Figure 38: TMA GHMI radar window



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 aircraftsorted by arrival runway and then time at the arrival runway gate.

- For the ACC sectors and STACK positions, the BaseAMD provides a tabular list ofall inbound aircraft coming via the Metering Fix in the sector/stack, sorted by timeat the Metering Fix.

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

Figure 38: AMD GHMI



7.2.3. Vertical View Display (VVD)

The Vertical View Display (VVD) is available to controllers in a number of differentsectors. Each PD/3 Organisation requires slight differences in VVD, in addition to theSPL 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 STACKsectors related to the appropriate Metering Fix. The important SPL data concerningflight 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 dataconcerning flight times is contained in the SPL predict list.

Figure 39: Holding area



7.3. ROLES AND WORKING PROCEDURES

In the PD/3CT advanced organisation a number of roles were defined. These are:

- En-route Planning Controller: ER-PC

- En-route Tactical Controller: ER-TC

- ACC Planning Controller: ACC-PC

- ACC Tactical Controller : ACC-TC

- Arrival Sequence Planner: ARR-SP

- TMA Tactical Controller: TMA-TC

- Stack Controller: SC

- Feeder Controller: FC

Each role comprises a number of tasks that need, or can, be executed. Below someexamples are provided for roles and their associated tasks.

Tasks are triggered by certain events. These events are described including theirrepresentation 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 anumber of actions have to be taken. These actions are described especially wherethey contain interactions with the ATC system. It may also be that these actions resultin 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 thedefinition of the PD/3 GHMI specification. The following model has been used by theengineers to implement and realise the complex GHMI in software.

Action4

Event

Task

Action1

Action2 Action3

Event

End ConditionAchieved

Figure 40: The software implementation model describing controller tasks



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 theGHMI. The state of an aircraft depends on the sector{xe "sector"}. For each sector anaircraft can have only one state. The state of an aircraft can however differ betweensector A and sector B. The following five states are used:

Not Concerned State Aircraft that will never be of concern to thesector{xe "sector"} (or never again). An aircraft thatis 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 beselectively filtered out from the controller’s displaywith the height filter.

Not Yet Plannable State An aircraft shall be classified as in the NOT YETPLANNABLE state until it enters the planningauthority of the position.

Advanced Information State These are aircraft for which it is possible to performplanning changes. Advanced Information stateshall indicates that the interaction with the aircraft ispermitted (i.e. the controller has the PlanningAuthority for this aircraft).

At the same time when an aircraft is converted intothe Advanced Information State, the label on thegiving sector displays the next sector name in theNS field.

NOTE: it is possible that this Advanced Informationcan be made available earlier by the use of theFORCED ACT option on the Callsign Menu by theprevious sector.

Assumed State These aircraft are on frequency and have beenassumed, i.e. they are under the sector’s currentcontrol.

Concerned State This concerns aircraft that are no longer underAuthority or Control but remaining physically withinthe Sector. Traffic that has been released, or trafficthat has been transferred out but which has not yetphysically left the sector.



The changes of state for each aircraft are mostly automatic. There are a number ofexceptions:

- Any planning controller may request early planning authority by using an input tothe system. This forces the concerned aircraft from Not Yet Plannable State inAdvanced Information State.

- Unequipped aircraft are manually assumed and released by the tactical controllerof a sector{xe "sector"}. This concerns the change from Advanced InformationState 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 toensure efficient organisation of traffic through the sector{xe "sector"}. This is done byassessing and resolving traffic planning conflict situations. The ER-PC mainly aims toresolve these planning conflicts but occasionally leaves problems to be assessedand/or solved by the tactical controller in a later stage.Flights are planned after acquisition of Planning Authority. The PCs can co-ordinatewith any PC of a giving or receiving sector on flight plan updates. Most of this co-ordination 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 arealready 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.



Below, three of such tasks of the ER-PC are described following the model describedearlier.

Task Number: ERPC_1Task description The ER PC shall analyse the flight information so as to integrate the

flight into the traffic situation.

Trigger event Aircraft state changes from Not Yet Plannable to AdvancedInformation.

Trigger representation The trigger is visualised in a number of ways on the GHMI:

• The label colour changes to pink (and if the aircraft will changelevel in the sector additional information is displayed in thelabel)

• An entry is made in the Sector Inbound List

• A message is presented in the message in window

Sequence of actions As a result of the trigger the following actions are/can be taken bythe ER-PC:

• The ER-PC assesses the information related to the flight inorder to update his mental picture of the situation

• If there are one or more planning conflicts detected by thesystem and indicated on the GHMI for this particular aircraft theER-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 thesector{xe "sector"} is acceptable to the control team (i.e. in principleconflict free).



Task Number: ERPC_2Taskdescription

The PC shall monitor the traffic for deviations from the planning and whennecessary he shall re-plan the aircraft.

Trigger event Aircraft deviates from plan

Triggerrepresentation

- The trigger is visualised on the GHMI in the following way: A yellowmarker circle is displayed around the position symbol of the aircraft

Sequence ofactions

As a result of the trigger the following actions are/can be taken by the ER-PC:

- He assesses whether the aircraft is in Advanced Information State orAssumed State.

- If the aircraft is in Advanced Information State it is under control ofanother sector{xe "sector"} and the deviation is not yet relevant to thiscontroller. He may however still decide to update the planning for thisaircraft to reflect the deviation from the current plan.

- If the aircraft is in Assumed State, it is in principle the responsibility ofthe TC to get the aircraft back to the plan. If the TC decides thatreplanning is the best solution he may delegate this task to the ER-PC. If the aircraft is already close to the exit of the sector it may alsobe decided to co-ordinate the need for replanning with the PC of thenext sector.

- If the PC has to update the planning he starts by loading the flightplan into the HIPS, clicking with the right mouse button on anyrepresentation of that aircraft’s callsign on the GHMI.

- He then assesses the need to modify any constraint based on theaircraft’s active plan, the deviation and the traffic situation. (He has tomake at least one modification to generate a new flight plan contextfor that aircraft, which can then be activated).

- When he is finished making modifications to the constraints he cangenerate a new trajectory prediction by bringing up the TrajectorySupport Tool and selecting the “validate” option.

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

- Whenever a new planning conflict is created in an adjacent sectorbetween the alternative plan and any existing plans, this triggers theneed to co-ordinate

Endcondition(s)

The task is completed when a new plan has been activated which takesinto account the deviation form the previous plan.



Task Number: ERPC_3Task description The PC shall resolve planning conflicts as much as possible

before the concerned aircraft are taken under control by thesector{xe "sector"}.

Trigger event A planning conflict is detected

Trigger representation The trigger is visualised in a number of ways on the GHMI: Aconflict symbol is created on the Conflict Risk Display (CRD),also indicating the callsigns of the aircraft concerned.

The “exit port” in the labels of the concerned aircraft changecolour to yellow. (only if the aircraft is either in the AdvancedInformation State or the Assumed State) (The label below is alsoinverted because it is selected)

The exit port in the SIL changes colour to yellow.



Sequence of actions As a result of the trigger the following actions are/can be taken bythe ER-PC:

- He assesses whether the aircraft are in Not Yet PlannableState, Advanced Information State or Assumed State.

- He identifies the aircraft for which he intends to change theplan. This aircraft can not be in the Not Yet Plannable State.

- If the aircraft is in Advanced Information State he loads itsactive flight plan in the HIPS by clicking with the right mousebutton on any callsign of this aircraft on the display (so eitherin the label, in the CRD or in the SIL).

- If the aircraft is in the Assumed State it is the responsibility ofthe ER-TC to resolve the problem. He may however delegatethis to the ER-PC.

- The ER-PC then modifies one or more constraints, therebycreating an alternative set of constraints. The HIPS displayinterface allows the controller to interactively see the effect ofhis changes on the conflict situation.



- When he is finished making modifications to the constraintshe can generate a new trajectory prediction by bringing up theTrajectory Support Tool and selecting the “validate” option.

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

•



- Whenever a new planning conflict is created in an adjacentsector{xe "sector"} between the alternative plan and anyexisting plans, this triggers the need to co-ordinate (seeError! Reference source not found.)

- If a planning conflict is detected in the sector that the PC isresponsible for, he has the option to modify the constraintsfurther, or to force the plan to become active, despite theplanning conflict.

- After any co-ordination has been completed or after the PChas forced the new plan to become active, the systemidentifies 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 theactive system plans.



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 asnecessary to their planning.Flights are controlled after acquisition of Control Authority, i.e. when the aircraft haschanged to the Assumed State.

Tasks

The following tasks are to be carried out by the ER-TC:

Task Number: ERTC_1Task description The ER TC shall maintain traffic situation awareness and be ready

to intervene with tactical clearances in the event of unexpectedconflict or urgency situations.

Trigger event Control of an equipped Aircraft is assumed automatically by thesystem (Note: The pilot of such an aircraft does not have to call inon the R/T).


• The colour of the aircraft label changes to White when theaircraft is automatically assumed by the sector.

• The entry for the aircraft is removed from the SIL.

• A message is presented in the message in window???

Sequence of actions This task does not consist of a number of specific actions that mustbe performed when the trigger occurs. However, the ER-TC willnormally as a result of the trigger perform the following action:

• He will assess the aircraft plan, initially through its labelinformation, to adjust his mental picture of the traffic situationand to anticipate possible future actions. He may also assessthe flight plan in more detail by looking at the AugmentedDynamic Flight Leg (ADFL) or the Extended Label Window(ELW).

End condition(s) The task is completed when the aircraft is transferred to the nextsector (i.e. it changes to the Concerned State)



Task Number: ERTC_2Task description The ER TC shall maintain traffic situation awareness for aircraft

that are no longer under his control responsibility but are still in hissector.

Trigger event An equipped Aircraft changes to the Concerned State or a nonequipped aircraft is released within the sector.


• The label of the aircraft is presented in the ‘concerned colour’(Mustard)

• A message is presented in the message in window

Sequence of actions As a result of the trigger the TC takes no particular actions. He willhowever keep monitoring the concerned aircraft against otherflights.

End condition(s) The task is completed when the aircraft actually leaves thesector’s airspace and changes to the Not Concerned State.



Task Number: ERTC_3Task description The ER-TC shall ‘manually’ assume control of a non equipped

aircraft.

Trigger event Such an aircraft is released by the previous sector{xe "sector"}and the pilot of the aircraft calls in on the R/T.

Trigger representation The trigger is presented in a number of ways:

• The pilot of the aircraft calls in to the sector using its R/Tfrequency.

• On the GHMI the representation of the callsign in the label ofthe aircraft is changed to the assumed colour (White).

• If the aircraft has not been assumed by the sector before theaircraft actually enters its airspace a box will be drawn inassumed colour (White) around the label as a reminder.

Sequence of actions As a result of the trigger the following actions are/can be taken bythe ER-TC:

• After matching the aircraft’s R/T callsign with the informationon the screen the TC will assess the need for any immediateaction for this aircraft.

• He will respond to the aircraft’s call by confirming theidentification and if necessary by giving it a clearance.

• When moving the mouse pointer in the label presentation onthe RPVD, the label will be presented in ‘filled-in’ mode. Hewill assume control of the aircraft by clicking with the leftmouse button on any representation of this aircraft’s callsignon the GHMI.

• After clicking with the left mouse button on the ‘ASSUME’button, the aircraft is assumed and the whole label will bepresented in assumed colour (White).

End condition(s) The task is completed when the TC has assumed control over theaircraft



7.4. INTEGRATION OF PHARE ADVANCED TOOLS

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 datalink-equipped 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 statedata 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 theyrequired 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 aircraftevery radar cycle. The PATs FPM monitors for the following:

- Deviation

Creation, Update and Deletion events are produced to indicate an aircraftdeviating outside of the planned tube given in its active SPL. Deviation from theplanned tube is given in terms of transversal, longitudinal, altitude and timedeviations. 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 equippedaircraft.

- 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 plannedtube. This advisory given in the event is used to pre-empt a potential deviationwhen 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 acombination of aircraft identity and significant point. This allows specific points inan aircraft's SPL to be monitored.For PD/3 at NLR this function has not been used by any other system componentthan the GHMI server.

7.4.3. Conflict Probe (CP)

There were a number of instances of the CP used, which consisted of two types – amain CP and multiple Alternative CPs.

Main CP

The main CP function is to probe for conflicts against all Active SPLs. The CPserver subscribes to receive all Active SPLs and whenever a new or updatedActive SPL is received, the CP probes it against the Active SPLs of all otheraircraft. The CP server maintains a database of conflicts creating, updating anddeleting them as appropriate.



If called directly to perform a probe on an Alternative SPL, this version of the CPwill probe the Alternative against the Active SPLs of all other aircraft. The serverwill 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 numberof Alternative CPs was required to perform the one-off probing of an AlternativeSPL. To achieve this, this instance of the CP still had to subscribe to receive andhold the data on all Active SPLs – but this instance of the CP did not perform anyprobing for conflicts whenever a new or updated Active SPL was received.Probing of Alternative SPLs for conflicts is performed in the same way asdescribed above for the Main CP. The Negotiation Manager server maintains a listof 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 specificairport (or configuration of runways). A graphical display window is available to theATCo'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 co-ordination and all air-ground co-ordination.

Whenever another component (e.g. GHMI or AM) has generated an alternative SPLwhich they want to register, the NM will be instructed to perform a negotiation on thealternative 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 theNM to check an Alternative SPL to see if a ground-ground co-ordination isrequired. If it is, the NM will send an event to the appropriate party(s) so that it cancheck the SPL. At this point the whole negotiation can be cancelled, counter-proposed or accepted. After any ground-ground co-ordination is complete, the NMwill perform an air-ground negotiation on 4D datalink-equipped aircraft. At the endof a successful air-ground negotiation or for non-4D datalink-equipped aircraftafter 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 andgo straight on to the air-ground negotiation. For a non-4D datalink equippedaircraft, this will just activate an SPL.

- Formalised Clearance this option is available to components with tacticalcontrol of an aircraft to override normal co-ordination and negotiation protocols. Fora 4D datalink equipped aircraft, this will mean an instruction to the pilot and on-board TP to fly “as best as possible” according to the up-linked set of constraintsand start flying straight away. For a non-4D datalink-equipped aircraft this willmean to activate the trajectory generated from the set of constraints as quickly aspossible.



- Aircraft Proposal

(4D datalink-equipped aircraft only). This option allows a pilot to propose a newtrajectory to the ground. The NM will determine which (if any) components need tobe informed about the proposal for their consideration. Should the trajectory passthe co-ordination filters, the trajectory will be accepted automatically. Only afterapproval from the ground-system will the aircraft be allowed to fly the proposedtrajectory. If the proposal causes conflicts or other problems it can also becancelled 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 atNLR, 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 alsoused to test alternative SPLs to indicate if any co-ordination is required. This is usedby the GHMI to provide visual indications about an alternative SPL that an ATCo isediting. The results of such a test is also used to dictate which form of negotiation theGHMI will allow through its graphical interface.

7.5. THE AIRCRAFT HMI

The aircraft was equipped with the experimental FMS. In adition to that, a modifiedPrimary 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 conflictfree ‘ 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 deviationsor trends towards potential deviations occur. Combined with the navigation displaydifferent ‘look ahead times can be served and both displays provide ample opportunityto build a ‘traffic awareness’ when other aircraft are also displayed. Such a display canbe generated through the ground- air datalink (slow update) or air-air datalinks likeADS-B (high update rate).



Figure 41: The cockpit of the NLR Citation aircraft with the Airborne Human MachineInterface

The use of such displays is still experimental and opinions on its benefits are underdebate. One example is the effect on visual workload. Its is well known that syntheticdisplays 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 exampleof a display format with superimposed eye fixations and transitions is depicted below.

Figure 42: Experimental ‘tunnel or bubble’ in the sky format, with superimposedeye fixation and transition data. Simulator experiment. For information, contactthe NLR.

Data obtained in several flight simulator experiments suggested that the opposite is infact more likely. The results of a comparison with the traditional PFD seemed to favourthe new design. An example of the results is depicted below.

30

40

50

60

before after

Eye

fixa

tions

/ m

inut

e

Conventional PFD

Tunnel type display

70

Auto pilot failure



Figure 43: Visual workload as indicated by eye fixations needed for two conditions:normal and after an auto pilot failure.

7.6. MAIN LESSONS LEARNT

The building of such a complex working environment is quite a challenge. Severalcontroller teams used the resulting system simultaneously and it was a great reward toall the designers that, after some time, the room became quite and the atmosphererelaxed, 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 theresponse times of tools. For any GHMI, swift system responses are critical. Anadditional replicated or consistent effect was that the dialogue of trajectory negotiationis still complex and fairly cumbersome. With all the new information and tools, asimplification should be realised. This seems feasible, as the original designs werecompliant with existing procedures. Already in PD1 it was discovered that transferringexisting conventions to new designs is not by definition effective. A similar lesson waslearned with respect to the glass cockpits where dials designs on computer screenswere not always as compliant as expected. So, these effects seem to be part of anatural evolution process. During the design phase, too novel features are deemed aspotentially unacceptable and the design is aimed at a transition. However, when thenew possibilities come to life, experience can be gained and the potential fullyexploited. Therefore, these designs provide excellent playgrounds for reconfiguring,studies and optimisation.

A second lesson learnt is that training proved quite essential and instrumental inenabling controllers to cope and adjust their controlling strategies to the newenvironment. Due to the time pressures involved, the training material needed, such asscreen dumps of GHMI components was not available in time. Therefore the trainingdesigners had to improvise and create their own pictures, simulations etc. As aconsequence, deviations or differences from the final system could occur and such aphenomenon will reduce training effectiveness. Some controllers, who had experiencefrom earlier PHARE demonstrations, complained that, although their previousexperience helped them in getting familiar with the system, differences with the “old”system were not always adverted. Clearly, highlighting such (essential) differenceswas 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 bemanageable and achievable. Optimised and tested training material will clearly assistin 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 convincedthat the trajectory display functionality was useful in resolving conflicts and the coloursused were easy to understand and use. Modifying a trajectory using the tools providedproved to be difficult for just over half of the controllers. From controller remarks itappears that 3D aircraft deviating from their planned trajectory increased the workloadsignificantly and that in the TMA planning by trajectory management was difficult dueto the high traffic loads.



7.7.2. TST

The Trajectory Support Tool (TST) turned out to be useful in simplifying co-ordinationand was easy to use for the majority of the controllers.

Use of the co-ordination tool proved to be difficult for some controllers, more seriouslywas the fact that for most controllers it was not clear with whom they were co-ordinating. In addition, the reason for co-ordinating was not clear for everyone. Twocontrollers explained the reasons why co-ordination was not easy quoting the systemto refuse accepting seemingly sound resolutions, not receiving any responses fromother controllers when trying to co-ordinate changes and the system requiring co-ordination when according to the controller this was not required.

7.7.3. Labels

Label (and overall) colour coding was appreciated by most controllers. The planningstatus of an aircraft was clear for all but one controller although a remark was madethat 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 conflictswere very much divided. From the remarks it appeared that CRD reliability was not toohigh (according to some controllers the CRD sometimes failed to identify losses ofseparation 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 CRDmade it difficult to use the CRD.

When accessing flight details, controllers preferred selecting the aircraft label asopposed to the Conflict Risk Display or Sector Inbound List (SIL). The SIL was notused 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), timecontrol proved to be the most difficult one to use. One controller remarked that due tothe (small) size of the specific sector it was not able to use time control. Lateral controlseemed to be acceptable but the acceptance of level control showed widely dividedcontroller opinions. From controller remarks, issues with level control seem to beconflicts being displayed when controllers were convinced of sufficient separationbetween two aircraft.

PHARE GHMI Project, Final Report Discussion


8. DISCUSSION

8.1. THE DESIGN PROCESS

8.1.1. The specification format

The specification format changed and evolved during the work itself. In PD1 there wasa close relation between the GHMI team and the software developers that led to amutual understanding of the issues to be resolved. In that situation, text was sufficientto allow the software designers to do their work. In later parts of the project, tasks werecarried out more independently. The main reason for this was due to the fact that partsof the programme were overlapping. So, some of the GHMI team members were stillprocessing data from PD1, while others were specifying the PD2 GHMI. This limitedthe opportunities for multi-disciplinary interaction as resources became more scarceand 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/outputrelations between system components and their timing. So, PATS tools designerscould more easily modify the software to fit the overall configuration. Otherimprovements made were the inclusion of summary tables of functionality in thespecification. Also, summaries of colour coding, basic mechanisms etc. were added.With such assistance, the software designer can have more easy access to thespecification.

However, the software specialist still had to study and absorb the total material todecide on the most efficient coding strategy. The material proved to be so vast, that nosingle designer was able to absorb all details. Better or more compatible formats haveto 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 allowa more reduced specification that contains ‘high confidence’ HMI utilities.

Unfortunately, the available prototyping tools were not really flexible enough to assistsuch a process. Response times fall down as a function of new elements added thatare not a part of the regular library. As a consequence the first hard coded PD1software had to be re-used, altered, extended etc. If a team is available that knowssuch 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) isprovided in the annex. A high level discussion on specification issues is also availablein the annex.

Discussion PHARE GHMI Project, Final Report


8.1.2. The evaluation process

The reliance on subjective ratings and personal appreciation’s of controller workingpositions has been reduced by the development of more objective means forassessing human performance and strategies in using the GHMI. Measures such aseye-scanning and other psycho-physiological parameters proved essential inunderstanding why certain behaviours occurred. These measures proved very usefulduring the exploratory experiments but were not applied during the maindemonstrations. Several reasons existed. Firstly, the use of such measures requiresspecialists and advanced equipment only available for one of the partners. Thepressure of the demonstrations is so high that the responsible parties tend to adopt astrategy of scope reduction and that immediately affects the quality of the evaluationand the tools used for that. Furthermore, some of the techniques used were stillexperimental and not yet proven, thereby reducing the willingness to incorporate thembeforehand.

Still a lot of useful data has been obtained and processed. It could have been muchmore if the experiments were conducted on a smaller scale first, in stead of going forthe full world in one go. However, smaller scale experiments tend to raise questions tobe resolved first, thereby making it more difficult to plan the big demonstrations. Whatthe best strategy will be, has to be decided in follow-on projects.

One aspect is however very clear. The PHARE programme has resulted in ATMsystems that include many facilities that can be re-used effectively for furtherinvestigations. The equipment and procedures for more objective validations has alsobeen proven and is ready for future use.

8.1.3. Controller acceptance

Initially, controllers were quite sceptical about the use of a windowing environment andother facilities that seemed to drag the design away from a traditional radar display.However, when time passed and more and more controllers gained experience withthe designs in realistic simulations, acceptance increased. The factor of hands-onexperience seems instrumental in gaining such acceptance. The emphasis on thesimulations seems more than justified, based on this argument. The internationalcollaboration proved very supportive in allowing may controllers access to the system,allow exchange of experiences and tips for improvements, resulting in a ‘invented byus’ attitude. Clearly, it has been a project with intensive multi-disciplinary interactionsthat really helped in getting advanced ATM off the ground.

As a result, many of the PHARE GHMI elements now integrated in the new EATCHIPbaseline design and the United States FAA has raised considerable interest inadopting the design for its own purposes. Also, ATC providers within PHARE havealready performed some additional experiments to tailor and improve the design. Sothere have been PD1 plus and PD2 plus experiments. The results are available, butthe work was an extension of the initial designs and not an integral part of the coreGHMI project. Some participants in the programme even felt a bit left out of such, initself positive, follow-on actions. Such a development should be better co-ordinated ifcontroller acceptance is to be gained at a more European or even global level.

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 trainingmaterial seem to have been major factors in accomplishing these positive results.Training should never be underestimated, as additional training could possiblyameliorate the phenomena of ‘high traffic panic’. The training tools available in theprogramme were not part of a full scope, training project. They can be compared withband-aids for problems noted during the development process. These band-aids wereeffective, but future programmes should include training analysis and design from thevery 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 beperformed effectively by the planner controller. As a result the tactical controller hadlittle or nothing left to do. As controllers are highly motivated to provide the bestavailable service, the tactical controllers sometimes intervened. The result was that theplanning was disrupted causing confusions and leading to additional team work. Someeven argue that a tactical is not required anymore and that the resources freed, couldbe used for other purposes. Clearly, studies in such a direction seem promising in thelight of a possible reduced availability of controller candidates in the future. Theavailability of the PHARE technologies can be effectively used to study the feasibilityand 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 onobservations on controllers strategies under (very) high traffic loads. Under high trafficvolumes, controllers tended to revert to their basic nature with respect to strategy andworking methods. Under pressure, typically the centre of the screen is monitored andthe controller is concentrating on particular aircraft. The tools, that were designed toassist especially under such conditions, are not used anymore! This phenomenon hasbeen denoted as the ‘high traffic panic’ response. It is noteworthy to mention thatcontrollers are most often unaware of this change in strategy. Objective behaviourdata indicates that level of experience is a mediating factor in deciding at whichparticular traffic load this behaviour will be initiated.

More work is required to study this effect in more detail as it poses a risk for thetransition 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 theoverall traffic awareness can be reduced. The big picture is still a highly appreciatedconcept and the impact of advanced tools and working methods are yet poorlyunderstood. 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.

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 trajectorygeneration system and the ground based conflict probe. The controller would only beinvolved in case of a conflict, and not when there are no implications for overall trafficconflicts. In such a case, the basis for a ‘big picture’ could brake down leaving thecontroller in a reactive mode in stead of a proactive mode. For many reasons such amethod 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 witha certification standard of ATM (that is still non-existing).

PHARE GHMI Project, Final Report Conclusions


9. CONCLUSIONS

9.1. THE DESIGN GOALS

It can be concluded that the GHMI actually reached its original design goals. Thedesigns were completed in time and did not delay the overall project schedule. Thecontrollers who worked the prototypes gave us confidence that many of the principlesand guidelines proposed by GHMI will be adopted in the new generation of HMI’s.Clearly, research will be needed to refine the present designs and improve them whererequired. The obtained data with these designs revealed that overall workload wasindeed reduced to such levels that some of the controllers actually were left with littleto do. This was not an intended result, but partly a consequence of the focus on moreadvanced planning functions, a core element of the PHARE concept. The initialstrategy of GHMI was to design a generic, multi-purpose controller working positionthat 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. Itsubsequently served as an input for a renewed discussion on future staffing andtransition requirements for ATM systems.

9.2. CONTROLLER SKILLS

Based on the overall results within the programme, it still seems feasible to configurethe systems in such a way that the transition from older to newer systems can beaccomplished without major difficulties. One way could be to design update packagesthat include a subset of the tools. Controllers would be allowed to gradually absorb thepotential of the new tools before going to a next update. Additional studies are clearlyindicated on this issue. However, if all the potential of advanced technologies has to beexploited, major changes in roles and working methods cannot be excluded. So, theexpectation for that case is that ‘controller skills will never be the same as before’. Theavailability of the option for gradual transitions by re-configuring into subsets couldpositively influence the feasibility of an acceptable transition or expansion of suchskills.

However, we realise that PHARE focussed on the nominal situation. Much workneeds to be performed on the non-nominal conditions, before actual implementationcan be pursued.

PHARE GHMI Project, Final Report



PHARE GHMI Project, Final Report Recommendations


10. RECOMMENDATIONS

10.1. FUTURE USE OF RE-CONFIGURABLE TOOLS AND GHMI

The PHARE technologies and simulation platforms seem to provide a uniqueopportunity to investigate possible future configurations. Modifications can be madefairly easy and its impact on controller performance and safety investigated. Issueslike non-nominal conditions were not yet included and clearly need attention. It has tobe realised that all tools and technologies have not been fully validated. They weredesigned and used effectively, but in limited scenarios not yet using the full complexityof possible traffic patterns. PHARE provides the necessary harmonised platformscapable 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 notrealistic 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-basedcapability is therefore quite attractive as airlines directly feel the benefits all over theworld. However, the 4D concept seems to have essential benefits that are as good orat least complementary to the functions of airborne-based systems. A ‘best of bothworlds’ approach seems in order to adequately cover low and very high traffic densityareas. Exploratory studies in such direction indicate that such a marriage could befeasible 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, trafficawareness and ASAS.

- Non nominal conditions need validation.

- Training issues need to be explored further.




PHARE GHMI Project, Final Report Acknowledgements


11. ACKNOWLEDGEMENTS

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




PHARE GHMI Project, Final Report Glossary, List of Acronyms


12. GLOSSARY, LIST OF ACRONYMS

ACRONYM Meaning

AAS Advanced Automation System

ACC Area Control Centre

ACC-PC ACC Planning Controller

ACC-TC AAC Tactical Controller

ADFL Augmented dynamic flight leg

AERA Automated En Route Air Traffic Control

AHMI Airborne Human Machine Interface

AM Arrival Manager (PATs)

AMD Arrival Management Display

APD Activity Predictor Display

APP Approach Centre

APP Approach Sector

ARR SP ARRival Sequence Planner

ATC Air Traffic Control

ATCO Air Traffic Controller

ATM Air Traffic Management

BaseAMD Base Arrival Manager Display

BaseAM Base Arrival Manager

CENA Centre d’Etudes de la Navigation Aérienne (France)

CFMU Central Flow Management Unit

CLW communications list window

CMS Common Modular Simulator

CP Conflict Probe (PATs)

CPDLC Controller Pilot Data Link Communications, (an air-ground D/L application)

CRD Conflict Risk Display

CT Cooperative Tools (PATs)

CWP Controller Working Position

CZW conflict zoom window

DEP DEParture controller

DEP TC DEParture Tactical Controller

DFS Deutsche Flugsicherung GmbH

DLR Deutsche Forschungsanstalt für Luft- und Raumfahrt (Germany)

DM Departure Manager (PATs)

Glossary, List of Acronyms PHARE GHMI Project, Final Report


ACRONYM Meaning

DRA Defence Research Agency (UK)

EATCHIP European Air Traffic Control Harmonisation and Integration Programme

EATMS European Air Traffic Management System

EFMS Experimental Flight Management System

ER En-Route

ER PC En-Route Planner Controller

ER TC En-Route Tactical Controller

ETMA Extended Terminal Manoeuvring Area

FAA Federal Aviation Administration (USA)

FC Feeder Controller

FPM Flight Path Monitor (PATs)

GHMI Ground Human Machine Interface project

GRIGRI Gestures, Recognition on Interactive Graphical Radar Images

GSNA Ground-Supported Navigation Advisory

HAW Horizontal Assistance Window

HIPS Highly Interactive Problem Solver (PATs)

HMI Human Machine Interface

ICP Internal Clarification Project

MIW Message In Window

MMI Man-Machine Interface

MOW Message Out Window

MSP Multi-Sector Planner

NARSIM NLR ATC Research Simulator

NLR Nationaal Lucht- en Ruimtevaartlaboratorium (Netherlands)

ODID Operational Display and Input Development

OTF Operational Task Force (PD/3)

PATs PHARE Advanced Tools

PD PHARE Demonstration

PD/1 PHARE Demonstration 1



PHARE Programme for Harmonised Air Traffic Management Research inEUROCONTROL

PRORES PROblem RESolution

PROSIT PROblem SITuation

PS Problem Solver (PATs)

PHARE GHMI Project, Final Report Glossary, List of Acronyms


ACRONYM Meaning

PVD Plan View Display

R/T Radio / Telephony

RTO Ready for Take Off

RWY Runway

SC Stack Controller

SIL Sector Inbound List

SPL System Plan

STCA Short Term Conflict Alert

STU Selected Trajectory Update

SWIFT Specifications of Working position in Future Air Traffic Control

TC Tactical Controller

TC-APD Tactical Controller Activity Predictor Display

TDB Track Data Block

TEPS Trajectory Editor and Problem Solver

TLX (NAA) Task Load Index

TMA Terminal Manoeuvring Area/ Terminal Control Area

TMA-TC TMA Tactical Controller

TP Trajectory Predictor (PATs)

TPDR Transponder

TST Trajectory Support Tool

VAW Vertical Assistance Window

VHF Very High Frequency




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 theFirst 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 andhuman 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 memorandum103885. 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. Wright-Patterson Air Force Base, Ohio: Armstrong Medical Research Laboratory.

Boswell, S.B., Andrews, J.W. & Welch, J.D. (1990).

Recommended Literature PHARE GHMI Project, Final Report


Analysis of the Potential Benefits of Terminal Air Traffic Control Automation (TATCA). InProceedings 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 Proceedingsof 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 FourthInternational Symposium on Aviation Psychology. (pp. 186-189). Columbus, Ohio: Ohio StateUniversity.

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/RD-95/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 workloadestimation techniques in a simulated flight task emphasizing communications load. HumanFactors, 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. In D.L. Damos [Ed.], Multiple TaskPerformance. London: Taylor & Francis.

Credeur L. & Capron W.R., (1989).Simulation Evaluation of TIMER, a Time-Based, Terminal Air Traffic, Flow-ManagementConcept. 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 andTheory. New York: Plenum Press.

Damos, D. (1992). Dual task methodology: some problems. In D.L. Damos [Ed.], MultipleTask Performance. London: Taylor & Francis.



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 inHuman 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 HumanFactors 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 Associationfor Aviation Psychology, 21st Conference. March 1994-- Dublin, Ireland.

Endsley, M. R. (1992).Situation Awareness: A Fundamental Factor Underlying the Successful Implementation of AIin the Air Traffic Control System. Paper presented at the NASA/FAA workshop on AI and HFin 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 7thInternational 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). NewYork: 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 TechnicalMemorandum 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. InProceedings of the Human Factors Fociety, 31st Annual Meeting (pp. 156-160).



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 Wileyand Sons.Gosling, GD (1987).Identification of artificial intelligence applications in air traffic control. TransportationResearch, 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 paper2525.

Harris, W.C., Hancock, P.A., & Arthur, E. (1993).The effect of taskload projection on automation use, performance and workload. Proceedingsof the Seventh International Symposium on Aviation Psychology. Columbus, Ohio: Ohio StateUniversity.

Hart, S. & Wickens, C.D. (1990).Workload assessment and prediction. In H.R. Booher [ed.] MANPRINT: An EmergingTechnology, Advanced Concepts for Integrating People, Machine, and Organization. NewYork: Van Nostrand Reinhold.

Hart, S.G. (1990).Pilots' workload coping strategies. In Challenges in Aviation Human Factors: the NationalPlan. 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 andEnvironmental Medicine. May, 402-410.

Hart, S.G. & Stavelend, L.E. (1988).Development of the NASA-TLX (Task Load Index): results of empirical and theoreticalresearch. 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: CurrentResearch and Trends. Hillsdale, New Jersey: Erlbaum.

Harwood, K (1993).Defining human-centered issues for verifying and validating air traffic control systems. In JAWise, VD Hopkin & P Stager [Eds.] Verification and Validation of Complex Systems: HumanFactors Issues. Berlin: Springer-Verlag.



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-relatedtasks. In N. Johnston, R. Fuller & N. McDonald [Eds.], Aviation Psychology: Training andSelection. Hampshire, England: Ashgate Publishing.

Hilburn, B., Singh, I., Molloy, R., & Parasuraman, R. (1992)Training and Adaptive Automation: Non-adaptive Feedback Training. Technical report CSLN92-1, Cognitive Science Laboratory.

Hockey. G. (1986).Changes in operator efficiency. In K. Boff, L. Kaufman, & J. Thomas (eds.) Handbook ofPerception and Performance (vol II). New York: Wiley.

Hopkin, V.D. (1996).Automation in air traffic control: recent advances and major issues. Proceedings of the SecondAutomatioin Technology and Human Performance Conference. Orlando, Florida: University ofCentral 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: ItsMeasurement 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.], Automationand 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 theIEEE, 77(11), November 1989, pp 1634-1642. New York: Institute of Electrical andElectronics 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 andTrends. Hillsdale, New Jersey: Erlbaum.

Houselander, P. & Owens, S. (1995). An Initial Assessment of the Effects of a Number of Computer Assistance Tools uponController Workload. CS Report 9503. London: Civil Aviation Authority.



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 trafficcontrol centres. Ergonomics, 21, 697-708.

ICAO (1996).Civil Aviation Statistics of the World, 1995. Montreal, Quebec, Canada: International CivilAviation Organization.

ICAO (1993).Increased ATC automation may be inevitable to handle increasing traffic and data. ICAOJournal, June 1993, pp. 16-20. Montreal, Quebec, Canada: International Civil AviationOrganization.

Idaszak, J.R. (1989).Human operators in automated systems: The impact of active participation andcommunication. 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 RightStuff. 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. InT. Sheridan and G. Johannsen [Eds.], Monitoring Behavior and Supervisory Control. NewYork: 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 AppliedPsychology, 47(3).

Jorna, P.G.A.M. (1991).Operator workload as a limiting factor in complex systems. In J.A. Wise [Ed.] Automation andSystems 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: Springer-Verlag.

Kahneman, D. (1973).Attention and Effort. Englewood Cliffs, New Jersey: Prentice Hall.Kahneman, D., Slovic, P. & Tversky, A. (1982). Judgment under Uncertainty: Heuristics andBiases. New York: Cambridge University Press.



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. ofpostgraduate 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 uncontrollablethreats. 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 ManualControl, 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 gounused. 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 andMethods (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 CR-145153. 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 routeenvironment. 37th Annual Air Traffic Control Association Conference Proceedings (pp. 122-130). 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 Man-Machine Studies, 39, 1-15.



MacLennan, R.N. & Peebles, J.W.E. (1996).Survey of health problems and personality in air traffic controllers. International Journal ofAviation Psychology, 6(1), 43-56.

Madni, A.M. (1988).The role of human factors in expert system design and acceptance. Human Factors, 30, 395-414.

McDaniel, J. (1988).Rules for fighter cockpit automation. In Proceedings of the IEEE National Aerospace andElectronics Conference. pp. 831-838. New York: Institute of Electrical and ElectronicsEngineers.

Meckliff,C and Gibbs, P (1993).PATs problem solver. In PHARE Forum: Scientific Seminar of the Institute for FlightGuidance 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.]. Evaluationof 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: SectorComplexity 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 ofthe Aerospace Medical Council, 23-27 April, 1995. Brussels, Belgium.

Moray, N. (1979).Models and measures of mental workload. In N. Moray [Ed.] Mental Workload: ItsMeasurement 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 AutomationTechnology and Human Performance Conference. Orlando, Florida: University of CentralFlorida.

Muir, B.M. (1987).Trust between humans and machines, and the design of decision aids. International Journal ofMan-Machine Studies, 27, 527-539.

Molloy, R., Deaton, J. & Parasuraman, R. (1996).Monitoring for automation failures using the EICAS display: effects of adaptive allocation onautomation. In Proceedings of the Second Automation Technology and Human PerformanceConference. Orlando, Florida: University of Central Florida.



Murphy, E.D. & Cardosi, K.M. (1995).Issues in ATC automation. In Cardosi, K. M & Murphy, E.D. (eds.). Human Factors in theDesign 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 inAviation, 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 anddevelopment (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 TrafficController. 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). MoffettField, 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 theiruse 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 CSL-A91-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.

Pélegrin, M. (1994).Electronic aids to controllers. In A. Benoît (Ed.) On-line handling of air traffic. AGARDdocument AG-321. Brussels: NATO.

Petre, E. (1994).Time based air traffic control in an extended terminal area. In A. Benoît (Ed.) On-line handlingof air traffic. AGARD document AG-321. Brussels: NATO.

Pew, R.W. (1979).Secondary tasks and workload measurement. In N. Moray [Ed.], Mental Workload: Its Theoryand Measurement. pp. 23-28. New York: Plenum Press.



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 ofAviation Psychology, 4(3), 211-240.

Rasmussen, J. (1979).Reflections on the concept of operator workload. In N. Moray [Ed.], Mental Workload: ItsTheory and Measurement. pp. 29-40. New York: Plenum Press.

Reason, J. (1988).Cognitive under-specification: its varieties and consequences. In B.Baars (Ed.) The Psychologyof 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 HumanFactors 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 airtraffic 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.) HumanPerformance 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 MachineStudies, 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 andR. Parasuraman [Eds.] Human Performance in Automated Systems: Current Research andTrends. Hillsdale, New Jersey: Erlbaum.

Sanders, A.F. (1979).Some remarks on mental load. In N. Moray [Ed.], Mental Workload: Its Theory andMeasurement. 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: CurrentResearch and Trends. Hillsdale, New Jersey: Lawrence Erlbaum.

Sarter, N.B. & Woods, D. (1991).Situation awareness: a critical but ill-defined phenomenon. International Journal of AviationPsychology, 1(1), 45-57.

Schneider, W. & Shiffrin, R.M. (1977).Controlled and automatic information processing. I: detection, search and attention. Bulletin ofthe Psychonomic Society, 18, 207-210.



Scott, B.C., Dargue, J. & Goka, T. (1991).Evaluation of Advanced Microwave Landing System Procedures in the New York TerminalArea. (DOT/FAA/ND-91/1). Washington, DC: US Department of Transportation, FederalAviation 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 FactorsSociety 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: CognitiveScience Laboratory, Catholic University of America.

Slattery, R. & Green, S. (1994).Conflict-Free Trajectory Planning for Air Traffic Control Automation. NASA Technicalmemorandum 108790. Moffett Field, California: NASA Ames Research Center.

Sperandio, J.C. (1971).Variations of operators'strategies and regulating effects on workload. Ergonomics, 14, 571-577.

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. USDepartment of Transportation.

Stein, E.S. (1991).Air Traffic Controller Memory: A Field Study. DOT/FAA/CT-TN90/60. Atlantic City, NewJersey: FAA Technical Center.



Stein, E.S. (1987).Where will all our air traffic controllers be in the year 2001? In Proceedings of the 4thSymposium 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/CT-TN90/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 computeraiding. 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 MonitoringTask: An Exploratory Study of Complacency and a Comparison of ATCs and Non ATCsPerformance. 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. HumanFactors, 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 andPerformance 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 ExperimentalPsychology: Human Performance and Perception. 6, 564-577.



Wickens, C.D., Kramer, A.F., Vanasse, L. & Donchin, E. (1983).Performance of concurrent tasks: a psychophysiological analysis of the reciprocity ofinformation 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-basedsimulation. 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), 725-736.

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. SanDiego: 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 aircraftsimulator. Human Factors, 25, 1-16.

Will, R.P. (1991).True and false dependence on technology: Evaluation with an expert system. Computers inHuman Behaviour, 7, 171-183.

Yeh, Y. & Wickens, C.D. (1988).Dissociation of performance and subjective measures of workload. Human Factors, 30, 111-120.

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 Universityof Technology, Department of Philosophy and Social Sciences.



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

PHARE GHMI Project, Final Report Annexes


14. ANNEXES

14.1. EXAMPLE OF GHMI SPECIFICATION FORMAT: THE ACTIVITY PREDICTOR DISPLAY.....147

14.1.1. APD | Description ..............................................................................................14714.1.1.1. APD | Figures ..........................................................................................................................................148

14.1.1.2. APD | Rules .............................................................................................................................................150

14.1.2. Primary APD | Window characteristics................................................................15214.1.3. Primary APD | Window Content ..........................................................................15314.1.3.1. Primary APD figures ...............................................................................................................................153

14.1.3.2. Figure comments.....................................................................................................................................153

14.1.4. Secondary APD | Window characteristics ...........................................................154

14.1.5. Secondary APD | Window Content .....................................................................15514.1.5.1. Secondary APD figures ...........................................................................................................................155

14.1.5.2. Figures 4.7, 4.8 and 4.9 legends ..............................................................................................................156

14.1.6. APD | Dialogues / Managing the APD display ......................................................15714.1.6.1. F4101 (GF4)............................................................................................................................................157

14.1.6.2. F4102 (GF4)............................................................................................................................................158

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

14.1.6.4. F4104 Adjusting the displayed time interval (GF4)................................................................................160

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

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

14.1.7. APD | Dialogues / Displaying / visualising filtered views .......................................16514.1.7.1. F1401 (GF1)............................................................................................................................................165

14.1.8. APD | Dialogues / Using look ahead displays ......................................................16714.1.8.1.1. .................................................................................................................................................................167

14.1.9. APD | Dialogues / Managing the PROSIT............................................................16914.1.9.1. F420 (GF4)..............................................................................................................................................169

14.1.9.2. PROSIT states figures .............................................................................................................................169

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

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

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

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

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

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

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

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..........................................................17914.1.10.1. F4301 (GF4)............................................................................................................................................179

14.1.10.2. PRORES states figures ............................................................................................................................180

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

14.1.11.2. F4402 (GF4)............................................................................................................................................183

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 ............................................................................................... 18714.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 .......................................... 19214.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. THE INITIAL ‘ROLE OF MAN’ DISCUSSION................................................................. 194

14.2.1. Introduction ...................................................................................................... 19414.2.2. Human Factors Contributions to Air Traffic Control.............................................. 19414.2.3. Research Programme ....................................................................................... 194

14.2.4. Conclusions ..................................................................................................... 197



14.1. EXAMPLE OF GHMI SPECIFICATION FORMAT: THE ACTIVITY PREDICTOR DISPLAY

APD WINDOW

14.1.1. APD | Description Phase : Mandatory

APD Window is used to provide special information related to air traffic. The window isorganised 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 trafficproblem) 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 atime axis. This specific view allows the controller to obtain a clear and chronologicalrepresentation of the clearances to be given to the a/c.



14.1.1.1. APD | Figures Phase : Mandatory

Figure 44: Primary APD



γ3

Figure 45: Secondary APD



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 isautomatically 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 axisis used to display the PROSIT / the right hand part is used to display thePRORES.

• The transfer line and the transfer symbol are displayed in the left hand partof the time axis of the PC primary APD only. They indicate to the PC thetime limit after which the PROSIT will be automatically transferred to theTC.

• The secondary APD button (generic P) placed on the right hand side of theAPD header and the arrow button placed on the right hand side of theAPD bottom edge , allow the controller : to be informed of activepreparations (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 ifa PREPLAB is reaching the time limit boundary. In this case the secondaryAPD button is available.

• The PRORES are not displayed in the PC primary APD.

• The secondary APD is displayed :

• The left hand part (interrogation mark side) is occupied by the PREPLABwhich have not been acknowledged yet by the mean of the function F4401or F4402.

• The right hand part (planning mark side) is occupied by the PREPLABwhich 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 themean of the ‘PRORES Problem spy hole’ or the ‘PROSIT Problem spyhole’.

• The controller can perform the following actions through the ‘Problem spyhole’ : displaying the STU mode if a new PROSIT is displayed (see F1401)/ displaying a characterisation of the PRORES if a new PRORES isdisplayed.

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



• A new event always takes the previous event place in the ‘Problem SpyHole’ even if the controller has not performed any action on it.

• The previous rule is not available if the secondary APD is displayed usingthe ‘Maintain Mode’. In this case, a new event (PROSIT or PRORES) doesnot make disappear the Problem Spy Hole contents. It just induces theactivation of the primary APD arrow. A new PROSIT or PRORESdisplayed in the Problem Spy Holes is removed only if an action isperformed on it.

• The secondary APD is provided with a specific alarm field (PRORES alarmor PROSIT alarm) which are respectively activated when a PRORES or aPROSIT reaches the time limit boundary.

• The PROSIT (PRORES) Problem spy hole display is erased as soon asthe PROSIT (PRORES) alarm field is activated (to avoid confusionbetween a new PROSIT (PRORES) and a PROSIT (PRORES) that hasreached the time limit boundary).

• If a new PRORES / new PROSIT appears, a time-out is initiated which willmake automatically the APD back to the primary APD after a 15 sduration. This time-out will be cancelled as soon as any action isperformed 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 longerthe display of the secondary APD. In fact the time-out (5 s duration) stillexists but it is activated only when a PRORES or a PROSIT reaches thetime limit boundary (alarm zone).

• The primary APD button placed on the middle of the APD header and thearrow button placed on the right hand side of the APD bottom edge , allowthe controller to access to the primary APD.



14.1.2. Primary APD | Window characteristics Phase : Mandatory

Window display attributes : Primary APD

Frame Border Line style Single, solid

Line colour Black / yellow

Square / Roundcorners

Square

Header Number of lines 1

Background colour Grey

Header text Generic P

Text colour Black / yellow

Text fonts parameters 14 pt Sans SerifCaps

Background colour W Grey

Default size Fixed

Minimum size -

Maximum size -

Default position Right part of thescreen

Priority on invocation 5

Associated Toolbox No

Status (parent / child / independent) Independent

Window behavioural attributes

Move No

Re-size No

Re-scale No

Iconify / De-iconify No

Close System

Open System

Scroll / Pan (page, incremental, manual) Yes



14.1.3. Primary APD | Window Content Phase : Mandatory

14.1.3.1. Primary APD figures

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



14.1.4. Secondary APD | Window characteristics Phase : Mandatory

Window display attributes : Secondary APD

Frame Border Line style Single, solid

Line colour Black

Square / Roundcorners

Square

Header Number of lines 1

Background colour Grey

Header text APD

New PRORES orPROSITdenomination

PRORES orPROSIT alarm text

Text colour Black / red

Text fonts parameters 14 pt Sans SerifCaps

Background colour W Grey

Default size Fixed

Minimum size -

Maximum size -

Default position Right part of thescreen

Priority on invocation 4

Associated Toolbox No

Status (parent / child / independent) Independent

Window behavioural attributes

Move No

Re-size No

Re-scale No

Iconify / De-iconify No

Close System

Open System

Scroll / Pan (page, incremental, manual) Yes



14.1.5. Secondary APD | Window Content Phase : Mandatory

14.1.5.1. Secondary APD figures

3

Figure 50: Secondary APD header content

γ

Figure 51: Secondary APD top edge content

Figure 52: Secondary APD bottom edge content



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)



14.1.6. APD | Dialogues / Managing the APD display Phase : Mandatory

14.1.6.1. F4101 (GF4)

Purpose To visualise the secondary APD to consult the currentPREPLAB

Procedure Manage APD / APD / secondary

Dialogue zone Secondary APD button, secondary APD arrow

Constraints The primary APD is displayed

There is an existing preparation at minimum

Particularities The secondary APD display, activates a time-out in order toreturn automatically to the primary APD

The effects take place only in the module in which the action hasbeen initiated

P1 Actions Effects

1.1 1 Single click B1 on the secondaryAPD button.

• The primary APD is removed.

• The secondary APD is displayed.

1.2 1 Single click B1 on the secondaryAPD arrow.

• Same effects



14.1.6.2. F4102 (GF4)

Purpose To return to the primary APD display

Procedure Manage APD / APD / primary

Dialogue zone Primary APD button, primary APD arrow.

Constraints The secondary APD is displayed

Particularities The effects take place only in the module in which the action hasbeen initiated.

P1 Actions Effects

1.1 1 Single click B1 on the primary APDbutton.

• The secondary APD is removed.

• The primary APD is displayed.

1.2 1 Single click B1 on the primary APDarrow.

• Same effects.



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

Purpose To change the scale of the time axis for both primary and secondaryAPD

Procedure Manage APD / APD / scale mode

Dialogue zone Primary APD, inferior value


The function is available on the primary APD only

Particularities The effects take place only in the module in which the action has beeninitiated

The effects take place on both primary and secondary APD

The values are displayed in the relative mode by default

P Actions Effects

1 Single click B3 on the inferior value ofthe time axis.

m (the values are displayed in the relativemode). The values switch to the absolutemode.

m (the values are displayed in the absolutemode). The values switch to the relativemode.

Figure 54: Inferior value in the alarm zone



14.1.6.4. F4104 Adjusting the displayed time interval (GF4)

Purpose To increase or decrease the time scale in order to visualise more or lessPROSIT, PRORES or PREPLAB

Procedure Manage APD / APD / scale

Dialogue zone Primary APD, superior value, superior arrow, inferior arrow



The effects take place on both primary and secondary APD

If the superior value is equal to t0 (current time) plus 25 min, thesuperior arrow is not available

If the superior value is equal to t0 (current time) plus 5 man, theinferior arrow is not available

P Actions Effects

1 Place the cursor on the superior valuefield.

• The extended field with both superior andinferior arrows is displayed.

2...

Single click B1 on the superior arrow. • The superior value (n) is increased to then + 5 min value.

• The APD labels (PROSIT, PRORES,PREPLAB) are moved to their newposition corresponding to the new selectedscale.

or

2

...

Single click B1 on the inferior arrow. • The superior value (n) is decreased to then - 5 min value.

• The APD labels (PROSIT, PRORES,PREPLAB) are moved to their newposition corresponding to the new selectedscale.

• The APD labels that are placed on a timeposition which is superior to the newselected superior value are removed fromthe APD.



Figure 55: Inferior and superior arrows of the superior value



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

Purpose To modify the automatic transfer time limit of the PROSIT from thePC primary APD to the TC primary APD

Procedure Manage APD / APD / transfer

Dialogue zone PC primary APD, transfer symbol


The transfer line cannot be moved inside the alarm zone

Particularities The function is available on the PC primary APD only

P Actions Effects

1 Press and drag B1 on the transfersymbol.

• The transfer line is moved to the bottom orthe top of the APD following the motionof the cursor.



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



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

Purpose To select the mode that allows the controller to keep the secondaryAPD display for a longer time

Procedure Manage APD / APD / Maintain

Dialogue zone Secondary APD, maintain mode button



P : if activated the maintain mode is cancelled

P Actions Effects

1 Single click B1 on the maintain modebutton in the secondary APD.

• The time-out for secondary APD removalis initiated when a PRORES or a PROSITreaches the time limit boundary (alarmzone).

Figure 57: Maintain mode button



14.1.7. APD | Dialogues / Displaying / visualising filtered views Phase : Mandatory

14.1.7.1. F1401 (GF1)

Purpose To get access to a filtered view which is providing a clear trafficrepresentation centred on the selected problem (STU)

Procedure Additional information / filtered views / STU

Dialogue zone Secondary APD, Problem Spy Hole, PROSIT


In the STU mode only the conflicting aircraft TEDI are available for anew trajectory edition

Particularities If displayed the STU is removed

The effects take place only in the module in which the action has beeninitiated

Actions Effects

15 Single Click B3 in the PROSIT (in theprimary APD or in the Problem SpyHole).

• The standard RPVD switches to the STUmode.

• The STU menu is displayed on the bottomedge 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 (onlyfor them) are displayed with the redsections materialising the interactingzones.

- If they exist, the contextual aircraft aredisplayed in their current ‘Flight state’coding.

- The other aircraft are displayed using agrey coding.

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



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

1 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



14.1.8. APD | Dialogues / Using look ahead displays Phase : Mandatory

14.1.8.1.1.

Purpose To visualise the traffic situation centred on the problem subset in aextrapolated time

Procedure Additional info / ahead / PROSIT

Dialogue zone Primary APD, PROSIT


The STU mode is activated


P Actions Effects

1 Press and drag B1 on the PROSITclock.

• The pointing cursor switches to an ‘openhand’ cursor.

• The ‘Look ahead’ PROSIT is displayed.

• The look ahead vector is displayed fromthe PROSIT clock to the cursor andfollows the moving cursor.

• A mirror callsign label is displayed oneach trajectory of the significant aircraft.

• These mirror labels are moved along theircurrent trajectory accordingly to theextrapolated time (a/c label stay at a/ccurrent radar position).

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

1 Release B1. • The ‘open hand’ cursor returns to thepointing cursor.

• The look ahead vector is removed from thePROSIT.

• The mirror labels disappear.



Figure 58: PROSIT in the ‘Look ahead mode’



14.1.9. APD | Dialogues / Managing the PROSIT Phase : Mandatory

14.1.9.1. F420 (GF4)

Function not implemented

14.1.9.2. PROSIT states figures

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



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

Purpose To transfer a PROSIT to the PC before the automatic transfer limit

Procedure Communicate / Transfer

Dialogue zone Primary APD, PROSIT, transfer symbol

Constraints The PC primary APD is displayed

The function is not available for the TC

Particularities The transfer is made automatically 6 min before the problemoccurrence

P Actions Effects

1 Symbol click B1 on the transfer symbolof the PROSIT.

• The PROSIT is displayed in the TCprimary APD.

• The transfer symbol is removed from thePROSIT in the PC primary APD.

Figure 60: PROSIT with the transfer symbol



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

Purpose To remove a PROSIT from the APD without waiting for the systemproposal

Procedure Manage APD / PROSIT / remove 1

Dialogue zone Primary APD, PROSIT, dustbin icon



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 beremoved simultaneously

P Actions Effects

1...

Single click B1 on the PROSIT. • The PROSIT switches to the selectedcolour coding.

2 Single click B1 on the dustbin icon. • The PROSIT is removed from the APD.



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

Purpose To keep a PROSIT in the APD even if the system considers that thereis no longer problem

Procedure Manage APD / PROSIT / keep

Dialogue zone Primary APD, PROSIT, dustbin zone, NO field


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 notinduce any alarm when it will reach the alarm zone (it will simplydisappear as soon as it reaches the current time)

P Actions Effects

1...

Place the cursor on the dustbin zone ofthe PROSIT.

• The YES and NO fields are displayedabove the dustbin zone.

2 Single click B1 on the NO field of thePROSIT.

• The YES and NO fields are removed.

• The dustbin zone is removed.

• The PROSIT switches into the ‘KeptPROSIT’ coding.



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

Purpose To remove a PROSIT from the APD according to the system proposal

Procedure Manage APD / PROSIT / remove 2

Dialogue zone Primary APD, PROSIT, dustbin zone, NO field


A dustbin zone is displayed closed to the PROSIT

Particularities The effects take place in both PC and TC modules.

P Actions Effects

1...

Place the cursor on the dustbin zone ofthe PROSIT.

• The YES and NO fields are displayedabove the dustbin zone.

2 Single click B1 on the YES field of thePROSIT.

• The PROSIT is removed from the APD.

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



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

Purpose To remove all the HMI effects induced by the PROSIT (PRORES)time limit alert

Procedure Manage APD / PROSIT / alert

Dialogue zone Primary APD, PROSIT (PRORES), PROSIT / PRORES time limitalert icon


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 tobe acknowledged simultaneously

The function is available for the TC only

P Actions Effects

1...

Single click B1 on the PROSIT(PRORES).

• The PROSIT switches to the selectedcolour coding.

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

m (PROSIT context) The F4605 effects arecancelled

• (PRORES context) The F1204 effects arecancelled)



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

Purpose To allow the system to add a supplementary a/c in a PROSIT that hasbeen already consulted by the controller

Procedure Manage APD / PROSIT / system proposal 1

Dialogue zone Primary APD, PROSIT, YES field


The callsign of the a/c to be added and the ‘+’ question mark zone aredisplayed closed to the PROSIT


P Actions Effects

1 Place the cursor on the question markzone or on the proposed callsign.

• The YES and NO fields are displayedabove the proposed callsign and in place ofthe question mark.

2 Single click B1 on the YES field.

• The YES and NO fields and the proposedcallsign are removed from the PROSIT.

• The a/c is known by the system as a newa/c involved in the problem.

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



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

Purpose To keep the system from adding a supplementary a/c in a PROSIT thathas been already consulted by the controller


Dialogue zone Primary APD, PROSIT, NO field


The callsign of the a/c to be added and the ‘+’ question mark zone aredisplayed closed to the PROSIT


P Actions Effects



2 Single click B1 on the NO field.


• The proposed a/c is not involved in theproblem.



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

Purpose To allow the system to removed an a/c from a PROSIT that has beenalready consulted by the controller


Dialogue zone Primary APD, PROSIT, YES field


The callsign of the a/c to be removed and the ‘-’ question mark zoneare displayed closed to the PROSIT


P Actions Effects



2 Single click B1 on the YES field.


• The a/c is no longer known by the systemas an a/c involved in the problem.



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

Purpose To keep the system from removing an a/c from a PROSIT that hasbeen already consulted by the controller


Dialogue zone Primary APD, PROSIT, NO field


The callsign of the a/c to be removed and the ‘-’ question mark zoneare displayed closed to the PROSIT


P Actions Effects



2 Single click B1 on the NO field.


• The a/c is still known by the system as ana/c involved in the problem.



14.1.10. APD | Dialogues / Managing the PRORES Phase : Mandatory

14.1.10.1. F4301 (GF4)

Purpose The TC gives instructions by VHF and updates in real time the part ofthe STRAJ associated to each given instruction

Procedure Manage APD / PRORES / VAL

Dialogue zone PRORES, message field

Constraints Only for 3D a/c

The primary APD is displayed

The function is not available for the PC


P1 Actions Effects

1 Single Click B1 on the message fieldof the PRORES.

•

•

•

• The instruction is displayed on the radarlabel (line 3 or 4) within the correspondingfield (ahdg, asp, arc or CFL7).

• The instruction message is removed fromthe PRORES.

m (others instruction messages are still to bevalidated in the PRORES) The PRORES ismoved on the APD vertical time axis inorder to be placed at the new timecorresponding to the next instructionmessage to be validated.

m (it is either the single or the last messageof the PRORES list). The PRORES isremoved from the primary APD.

• The CLEARANCE marker is placed onthe new trajectory at the end of the partthat materialises the validated instructionmessage.

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



14.1.10.2. PRORES states figures

1 : Standard PRORES with asingle message

2 : Standard PRORES withseveral messages

3 : Extended PRORES

4 : Time limit alert on PRORES

Figure 63: PRORES symbolical coding states



14.1.11. APD | Dialogues / Managing the PREPLAB Phase : Mandatory

14.1.11.1. F4401 (GF4)

Purpose The TC acknowledge the trajectory preparation in order to register it asthe new STRAJ

Procedure P1 : via the PREPLAB

P2 : via the radar label

Dialogue zone P1 : secondary APD, PREPLAB, YES field

P2 : radar label, P symbol, YES field


The trajectory preparation has not been already acknowledged via thefunction 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).

P1 Actions Effects

1 Single Click B1 on the YES field of thePREPLAB.

• The trajectory preparation is registered asthe new STRAJ and is displayed inflashing green coding (for 3 s) on theRPVD in place of the current trajectory.

• The P symbol is removed from the radarlabel in both modules (PC and TC).

• The planning mark is displayed in the labeland in the SIL (if it exists) in place of the Psymbol.

• The PREPLAB is moved after a 3 s delayto the ‘planning mark side’ of thesecondary APD.



P2 Actions Effects

1 Single Click B1 on the OK field closeto the beginning of the trajectory inpreparation.

• Same effects.

Figure 64: OK field and prepared trajectory



14.1.11.2. F4402 (GF4)

Purpose The TC gives instructions by VHF and updates in real time thesegment of the STRAJ associated to each given instruction

Procedure Manage APD / PREPLAB / VAL

Dialogue zone PREPLAB, message field

Constraints Only for 3D a/c

The secondary APD is displayed



P1 Actions Effects

1 Single Click B1 on themessage field of thePREPLAB.

•

•

•

m (it is the first message and the function F4401 has notbeen performed on the PREPLAB).

• The trajectory preparation is registered as the newSTRAJ and is displayed in flashing green coding(for 3 s) on the RPVD in place of the currenttrajectory.

• The P symbol is removed from the radar label inboth modules (PC and TC).

• The planning mark is displayed in the label and inthe 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 tacticalsolution.

• The instruction is displayed on the radar label (line 3or 4) in the corresponding field (ahdg, asp, arc orCFL).

• The preparation message is removed from thePREPLAB.

m (others preparation messages are still to be validated inthe PREPLAB) The PREPLAB is moved on the APDvertical time axis to be placed at the new timecorresponding to the next preparation message to bevalidated.

m (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 newtrajectory at the end of the part materialising thevalidated message.



14.1.11.3. F4403 (GF4)

Purpose The TC refuses the trajectory preparation

Procedure P1 : via the PREPLAB

P2 : via the radar label

Dialogue zone P1 : secondary APD, PREPLAB, NO field

P2 : radar label, P symbol, NO field


The trajectory preparation has not been acknowledged via the functionF4402 procedure

P1 : The extended PREPLAB is displayed

P2 : The prepared trajectory is displayed


The action can be made by both PC and TC

P1 Actions Effects

1 Single Click B1 on theNO field of thePREPLAB.

•

•

• 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 APDafter a dt (3 s).

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

P2 Actions Effects

1 Single Click B1 on theNO field of thetrajectory preparation.

•

•

• The trajectory preparation is cancelled.

• The P symbol is removed from the radar label in bothmodules (PC and TC).

• The P symbol is removed from the SIL (if it exists).

• The PREPLAB is removed from the secondary APDafter a dt (3 s).

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



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

Purpose To remove all the HMI effects induced by the PREPLAB time limitalert

Procedure Manage APD / PREPLAB / alert

Dialogue zone Secondary APD, PREPLAB, PREPLAB time limit alert icon


One or more PREPLAB are displayed using the alarm coding


Several PREPLAB can be selected at a single time in order to beacknowledged simultaneously

The function is available for the TC only

P Actions Effects

1...

Single click B1 on the PREPLAB. • The PREPLAB switches to the selectedcolour coding.

2 Single click B1 on the PREPLAB timelimit alert icon.

• The F1201 effects are removed.

• The PREPLAB and the time limit alerticon in the secondary APD return to thestandard coding.



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 markside

3: PREPLAB with several messages placed in the question mark side

4: Extended PREPLAB (YES / NO fields and secondary message) with severalmessages 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



14.1.12. APD | Dialogues Phase : Mandatory

14.1.12.1. F4501 (GF4)

Purpose To visualise on the RPVD the new planned trajectory associated to thePRORES

Procedure Manage APD / associated info / CHAR

Dialogue zone Primary APD, Problem Spy Hole, PRORES, message field


Particularities P2 : If displayed the PRORES characterisation is removed

The effects take place in the module in which the action has beeninitiated

P1 Actions Effects

1.1 1 Press and HOLD B3 within themessage field.

• The callsigns of the significant aircraftcorresponding to the PROSIT aredisplayed temporarily using the warningcoding.

• The previous trajectory of the a/c istemporarily displayed on the RPVD.

P2 Actions Effects

1.2 1 Single Click B3 within the messagefield.

• The callsigns of the significant aircraftcorresponding to the PROSIT aredisplayed using the warning coding.

• The previous trajectory of the a/c isdisplayed on the RPVD.

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

P1 Actions Effects

1.1 1 Release B3. • The callsigns of the significant aircraftcorresponding to the PROSIT switch to theflight state coding.

• The previous trajectory of the a/c isremoved from the RPVD.



14.1.12.2. F4502 (GF4)

Purpose To visualise the tactical solutions messages in a PRORES which arenot displayed at a first level8

Procedure Manage APD / associated info / PRORES

Dialogue zone Primary APD, PRORES, arrow field


The PRORES presents an arrow field

Particularities the hidden messages are not activable


P1 Actions Effects

1 Place the cursor on the arrow field. • The extended PRORES is displayed after adt delay (0.5 s).

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

P1 Actions Effects

1 Move the cursor out of the PRORESfield.

• The extended PRORES is removed.

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



14.1.12.3. F4503 (GF4)

Purpose To visualise the trajectory preparation on the RPVD

Procedure Manage APD / associated info / Traj PREP

P1 : for a fixed mode

P2 : for a quick look mode

Dialogue zone Radar label, SIL, P symbol, PREPLAB, message field


Particularities P1 : if displayed the preparation trajectory is removed


P1 Actions Effects

1.2 1 Single Click B3 on the P symboldisplayed within the radar label orwithin the SIL if it exists.

• The preparation trajectory is displayed inaddition with the current STRAJ in theRPVD using preparation colour codingand using dashed line.

1.2 1 Single Click B3 in the message fieldof the PREPLAB.

• Same effects.

P2 Actions Effects

1.1 1 Press and Hold B3 on the P symboldisplayed in the radar label or in theSIL if it exists.

• The preparation trajectory is temporarilydisplayed in addition with the currentSTRAJ in the RPVD using preparationcolour coding and using dashed lines.

1.1 1 Press and Hold B3 in the messagefield of the PREPLAB.

• Same effects.

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

P2 Actions Effects

1.1 1 Release B3. • The preparation trajectory of the a/c isremoved from the RPVD.



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



14.1.12.4. F4504 (GF4)

Purpose To visualise the preparation messages in a PREPLAB which are notdisplayed at a first level

Procedure Manage APD / associated info / PROSIT

Dialogue zone Primary APD, PREPLAB, arrow / question mark field or arrow field(allocated fields)


(there are several messages) The PREPLAB presents an arrow /question mark field

(there is one message only) The PREPLAB presents question markfield

Particularities The hidden messages are not activable


P1 Actions Effects

1 Place the cursor in the allocated field. • m (there are several messages and theprepared trajectory has not beenacknowledged yet) The extendedPREPLAB is displayed after a ‘dt’ delay(0.5 s) showing the preparation messagesto be sent after the first one and the YES /NO fields.

m (there are several messages and theprepared trajectory has been acknowledgedbefore) The extended PREPLAB isdisplayed after a dt delay (0.5 s) showingthe preparation messages to be sent afterthe first one.

m (there is a single message and the preparedtrajectory has not been acknowledged yet)The extended PREPLAB is displayed aftera dt delay (0.5 s) presenting the YES / NOfields.

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

P1 Actions Effects

1 Move the cursor out of the PREPLABfield.

• The extended PREPLAB is removed.



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 contentmodification (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 removalproposition (GF4)

See ‘Summary of supplementary objects codings’

14.1.13.5. F4605 Being warned of a PROSIT time limit alert (GF4)

Purpose The controller is alerted that a PROSIT has reached alarm zone in theprimary APD

Procedure APD / problem events / PROSIT

Coding zones Radar label, limit time icon in the primary APD, PROSIT alarm fieldin the secondary APD

Constraints None

Particularities The alarm effects are displayed on both modules (PC and TC)

P1 Actions Effects

1 The PROSIT hasreached the alarm zoneboundary in theprimary APD.

•

•

• The significant a/c labels switch to the warning codingin the RPVD.

m (the primary APD is displayed) The PROSIT and thetime limit alarm icon switch to the alarm coding.

m (the secondary APD is displayed).

• The PROSIT specific alarm field is activated untilthe primary APD is back to the prior display(manually or automatically).

m (the maintain mode is activated) The primaryAPD is automatically displayed 5 s after thebeginning of the alarm.



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



14.2. THE 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 processof trying to integrate Human Factors into programmes that were essentially‘technology driven’ when they were conceived. This material formed the starting pointfor 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 asair traffic control systems has been accepted for many years. The nature of thecontributions of human factors as a discipline to air traffic control has graduallyevolved with changing air traffic control requirements, advancing technology, andacknowledgement of the breadth of human factors contributions that are required.These have been defined in a series of studies (Hopkin 1970, 1982, 1988) on humanfactors, and also in a series of authoritative reviews of air traffic control and of itsassociated research and development which include human factors contributionsalong 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 wasrecognised, the methods of applying human factors were in retrospect somewhatarbitrary, being influenced not only by needs and resources but also by funding andthe location of expertise. Recently the roles of human factors in relation to air trafficcontrol have become more clearly defined and more formalised. The United StatesNational Plan for Aviation Human Factors with its comprehensive compilation ofresearch issues to be addressed and the MANPRINT program as an example of aformalised mechanism for applying human factors to large systems have helped toformalise its roles and contributions. Recent ICAO interest represented by thepublication later this year (ICAO, 1993) of a human factors digest on air traffic controldemonstrates that the application of human factors in this context is becomingacknowledged world-wide. It is in this context that the PHARE 'Role of Man' projectshould be placed, as a further initiative to organise and specify the application ofhuman factors to an evolving programme, in this case the Programme of HarmonisedAir Traffic Management Research in EUROCONTROL (PHARE).

14.2.3. Research Programme

Perhaps the most essential point is that the human factor contributions to PHAREshould be planned as a programme and implemented as a programme. An implicationis that the human factors problems associated with the PHARE programme wouldseriously overstretch the resources and capabilities of any one nation or researchestablishment, but that collectively the research establishments contributing to theEUROCONTROL programme could make the required human factors contributions tothe PHARE programme effectively, provided that all the contributions made areplanned as a whole, and are constituents of a unified programme of work. Theseparate parts of the work must have sufficient in common with each other to enabletheir findings to be interpreted not merely in isolation but in relation to the programmeas a whole and to other findings being obtained elsewhere within PHARE,



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

THE NEED FOR ITERATION

The application of human factors advice and knowledge in relation to PHARE must tosome extent be an iterative process. As systems become more precisely defined, thecorresponding 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 mattersof planning and policy is different from the much more detailed level applied at thefinal system design and evaluation stages. ]t is important to provide human factorsadvice iteratively throughout the system evolution so that best human factors solutionsare not precluded by decisions taken at an earlier stage of system evolution for otherreasons, without realisation of their full human factors implications, particularly in theform of options which they exclude. A great deal of information is available about mostmodern aircraft in flight, from which a small selection is made which is appropriate andsufficient to represent those aircraft to the controller for the purposes of controllingthem as air traffic. As technological advances provide more and better informationabout each aircraft, and as the ways of controlling aircraft as traffic themselves evolve(for example from tactical intervention with single aircraft towards the planning oftraffic flows) the question must be reviewed from time to time of whether the means ofrepresenting aircraft as traffic which have served so well in the past will continue to bethe most appropriate means to represent air traffic in future, or whether novel, andperhaps highly innovate, alternative means should be tried. The combination of data inplan view with alphanumeric data in tabular form has always presented problems ofcognitive compatibility, and any solutions which circumvent this problem, perhaps byadopting neither approach, have a major advantage if they have avoided the need forcognitive integration of radically different kinds of information.



HUMAN MACHINE RELATIONSHIPS

When computer assistance was first introduced into air traffic control, there were fewfeasible human machine relationships. Essentially the human al first had to adapt tothe machine because the machine was not adaptable. There then followed a period astechnology advanced when the number and nature of roles which could be consideredfor human or machine allocation expanded rapidly, purely as a result of technologicaldevelopments. Only if a machine could fulfil a function, does it make sense to ask thequestion whether a human or machine should fulfil it. In this era the human wastherefore in a sense competing with the machine for functions and must lose, becausethe competition could occur only where machines appropriate for the functions couldbe developed and those machines would become relatively more efficient as a resultof their further development.

The next phase concerned the total replacement of the human by the machine. Thiscan be effective for basic tasks such as data gathering, storage, collation andpresentation. There was an attempt to make the machine and human complementary,but this relationship proved quite difficult to design and implement when it was firstproposed over twenty years ago and it was superseded by the notion of human andmachine as mutually symbiotic, although this would seem to preclude the notion ofmanual reversion in the event of machine failure which remained a humanrequirement.

More recently, machine developments have meant that the human may take over froma failed machine, be adapted to by the machine, or be interchangeable with themachine. It becomes conceivable to allow human or machine to fulfil particularfunctions in parallel, by duplication or optionally one with the other, in the sense thatthe allocation of a function to either human or machine need not imply that the othercannot or must never fulfil that function. In an era where future machines may beintelligent, adaptable, innovative, or flexible it seems clear that some future roles mustenvisage human and machine being mutually adaptable to each other, but theprinciples of how this is best achieved when both human and machine possess suchattributes as intelligence, flexibility, adaptability and a capacity to innovate are not yetclear. Technological advances have offered the further options that there can be fluidand not necessarily predetermined or fixed relationships between human andmachine, and such a principle if correct applied may be a means to ensure safety, tosmooth workload, and to allow Human and machine to be mutually supportive. Anultimate 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 revealsthat there are a very large number of kinds of relationships to choose from becausetechnical advances have continued to offer further options, yet all the original optionsare also still available. Existing knowledge about the various options varies greatlybecause some are long standing and some are recent. It is very unlikely that a singlekind of relationship would be optimum for all human functions in relation to machineswithin the PHARE programme and therefore the strengths and weaknesses of thealternatives need to be addressed to achieve the best balance between human andmachine.



Some issues clearly have to be addressed. It is vital that the human jobs seemsensible to those who perform them. It is essential that some form of feedback andlearning is incorporated so that controllers can benefit and improve from experience. Itis highly desirable to ensure that al] that is proposed within the PHARE programme isacceptable and engenders favourable attitudes towards it since these may be aprerequisite for their successful operational introduction ultimately. It may be that theissue of human intentionally needs to be addressed so that when a problem oremergency arises the human controller can inform the machine of his or her intentionsand enlist machine help in achieving human objectives. lt is also important to considerthe factor of observability. Many of the roles traditionally fulfilled in air traffic controlhave been fully observable by others in the workspace. lt is not nearly as easy toobserve and understand what is happening when most of the actions consist of dataentry. A further factor concerns legal responsibilities. lt is essential that the PHAREprogramme as a whole must ensure that where controllers have clearly defined legalresponsibilities the equipment, facilities and information they are provided with and theprocedures 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 objectivesare to the success of PHARE and the safety and efficiency of its final products, tooptimise the roles within it; to ensure that human and machine are correctly matchedand mutually supportive; to confirm that the PHARE programme itself and the airtraffic control systems it will lead to or influence will not harm those who work withinthem; and to provide satisfying, productive and valued work for future generations ofair traffic controllers. This implies that it is envisaged that there will continue to besignificant 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 termwithin PHARE, but this work should be supplemented by some longer term studies ontopics such as the evaluation of the potential benefits of further dynamic task switchingand sharing as these options become more technically feasible and refined.

ITERATIONS

An iterative approach is envisioned in the application of human factors, with the levelof detail at the human factors issues are addressed remaining in step with the level ofdetail of designs and specifications as they progressively develop during systemevolution. The broad task categories are expected to evolve towards more specifictasks 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. Thehuman as an information processing system should be utilised in the light of recentcognitive advances and understanding of human information processing much of isreviewed and discussed in this report. Emphasis on design should also restore theemphasis on objectives and reasons for them, with more work to ascertain thatobjectives have met and less to examine the minutiae of what is actually being done toachieve those



which may not always be very important. The stages in designing a human centredinterface described in this report should normally be followed, or at least relativelysimilar processes to those stages.

SINGLE UNIFYING PROGRAMME

The human factors contributions within PHARE need to be a single coherentprogramme which contains means to unify the parts of that programme with eachother since those parts may be conducted with different resources, establishmentsand staffs. Methods, measures, constructs,

'Experimental designs, traffic scenarios, specifications, equipment, forms of data,forms of computer assistance, display conventions, types and formats of inputdevices, knowledge, procedures, instructions and forms of training are all tools whichproperly applied, can contribute towards unifying the programme. At least several ofthese means of unification should be adopted throughout the programme so that thefindings 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 willneed to be tasked to ensure sufficient commonality beforehand so that the results ofdifferent studies will be interpretable in relation to each other, whatever the findings ofeach study may be.

Although the primary emphasis must be on the roles of controllers it is advisable thatany roles for supervisors or assistants to those controllers should be planned inconjunction with the controller roles and not as add-ons when the controller roles havealready been defined and when many of the options for efficient supervision orassistance may have been excluded.

WORK ELSEWHERE

There are opportunities to learn extensively from work elsewhere from theories, fromair traffic control experience, from applications of formalised human factors processes,and from other attempts to devise a programme of human factors research in air trafficcontrol such as that within the United States National Plan for Aviation HumanFactors. This work may not always produce evidence or procedures which are directlyapplicable to PHARE but often it will. Maximum use should be made of this workelsewhere 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 pastor currently being done elsewhere, it is also possible to build on the many establishedhuman factors principles and these are listed in an appendix. They should be treatedas guidelines, which are generally valid, since each depends on extensive evidence.These principles should be followed wherever possible with steps to confirm and verifytheir applicability to air traffic control.



TEACHABILITY

Given that there will be jobs for human controllers in air traffic control for aconsiderable time, it is essential that these jobs are sensible, make use of the relevanttraining, human knowledge and experience, and are acceptable to controllersthemselves and to others. Wherever a new task or function or role for controllers isproposed, not only is it essential to ensure that humans can perform their assignedfunctions safely and efficiently, but it is also essential to ensure that the humanfunctions are teachable and that appropriate training can be devised. In a programmeof studies and evaluations it is important to recognise any aspects of controllers' taskswhich were difficult to teach or which controllers did not perform as planned in order tomake suitable changes in the future training and to confirm the teachability of the newfunctions. Evidence on current differences between expert and novice controllersshould be applied to assess teachability and to ascertain level of progress duringlearning.

PROBLEM-DRIVEN APPROACH

A problem driven rather than a technology driven approach is advocated as the bestmeans to deploy the limited human factors resources available most efficiently. lt isenvisioned that best progress would be made by planning the evolutionarydevelopment of future human roles from current ones. Final objectives and intendedend states should also be defined, using a top down approach so that these twoapproaches can serve as mutual cheeks and means of identifying any residualproblems if there are disparities between them. The need to evolve from currentsystems is a practical necessity, but so is the need to define potential end states, sothat when they have been achieved, this can be recognised.

It is considered that in the earlier stages the technological innovations anddevelopments will serve primarily as support tools and the automation provided withinPHARE would remain essentially human centred. Ultimately, it will be necessary to tryand evolve principles for matching human and machine when both have attributessuch as innovation, intelligence, adaptability, and flexibility. New options are becomingtechnically available and the means of using them within PHARE must be addressed,although their full technical refinement whereby they can safely be applied within airtraffic 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 associatedteam roles. This should mean that most of the mechanisms and functions currentlyfulfilled by teams remain significant unimpaired or unaffected within PHARE, but it isprudent to check and confirm this rather than to assume it. The major developments inteam 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 notprimarily technical or human factors reasons but rather legal ones, to enable thecontroller to exercise responsibilities for which he or she is responsible. This criterionshould often be applied during the iterative process to ensure that no controller is everin the position of having the legal responsibility, but no means to exercise it orinsufficient knowledge to understand it.



HUMAN ERROR

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

TASK ANALYSIS

Some form of task analysis, including human information processing functions, isnecessary for learning and understanding the role of the human controller in relation tothe PHARE programme. This includes decisions on the controllers' picture, on thecontrollers' level of experience and on the controller’s responsibilities, although taskanalysis as a technique has its limitations and has to be supplemented by othermethods. Taxonomy of variables affecting controllers and tasks provides a usefulstarting point but such taxonomy of functions should never be treated as fullycomprehensive. Often factors are not fully treated such as, navigational sources, theforms of equipment and computer assistance provided, the degree of openness andobservability of the workspace, and the desirable level of situation awareness asrelevant factors differentiating controllers and their tasks. Nevertheless it provides abasis for a classification of many of the main variables, and such a basis is needed fordefining jobs, tasks, and functions. The chapter also provides a useful review andinitial taxonomy of some relevant cognitive factors in relation to air traffic control tasks,and also warns of some incipient problems, such as increased monitoring, reducedfamiliarity, new possible error sources, and decreased mutual collaboration betweencontrollers. The consequences of decisions about the specification of the human-machine interface in terms of the openness and observability of the workspace toothers should be cheeked as this determines the feasibility of certain forms ofsupervision and independent verification.

HUMAN-MACHINE INTERFACE

The design of the human machine interface has a crucial influence on determining therole of the human controller within PHARE. Only the information displayed or madeaccessible to the controller is available for use by the controller. Other information, nomatter how relevant it may be, can have no influence on human tasks. It is thereforevital, to define carefully all the information that may be needed and to make adequateprovision for it to be available. Similarly the only actions which the controller caninitiate are those for which some provision has been made in the specification of theinput devices provided. The controller may devise an intelligent and innovativesolution to a problem, but if the means to implement it are not provided then thatsolution couldn’t be adopted. The importance of the human machine interfacespecification is not only to ensure that all the known tasks are performed safely andefficiently, but also as the means to implement any policies there may be aboutintelligence innovation and flexibility. The specification of the workspaces and thehuman machine interface in particular should also encourage considerablecommonality across equipment and practices.



Human factors criteria, in addition to those of technical reliability, suitability, costefficiency, and expected benefits, should be applied to assess proposed forms ofcomputer assistance for controllers, and to match them with human capabilities andlimitations. These criteria must emphasise safety and performance, but should alsoinclude effects on teams, on observability, on human roles, and on human attitudes,including acceptability. Work may be needed to establish how the extensive existingevidence on the formation and effects of attitudes could best be utilised within thePHARE programme. As changes in the envisaged human roles become moreapparent, these should be related to the current selection criteria for air trafficcontrollers, to check whether new required controller attributes should be added to theselection procedure and whether some existing selection tests should be discarded asno longer appropriate.

Air traffic i.e. control uses a limited selection of the information available about aircraftin order to represent and control them as traffic. As the roles of human controllersevolve, it may be that the traditional forms of representing traffic may no longer be themost appropriate for the new forms of air traffic control that will be required. Moreextensive computer assistance will tend to dissociate the human controller further fromthe aircraft under his or her control, but it is an assumption and not a proven fact thatthis greater dissociation must be inherent less safe, and evidence may be needed todiscover whether or not such an assumption can be justified.

The human factors considerations on the role of man within PHARE envisage thatreal-time simulation must probably remain the primary investigative tool, but wheneverpossible it should be preceded by supplementary laboratory studies on simplersimulations and should also be followed by operational or field studies to confirm andvalidate the real-time simulations. Simulations cannot provide valid answers to everyhuman factors question, and their inherent limitations have to be acknowledged andcircumvented. 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 theresearch if valid will be implemented, even if they are not what was predicted or hopedfor. In human factors work, the whole is always more than the sum of the parts, andthis will apply to the PHARE programme and to the separate parts of it. The need tobe able to interpret these parts in relation to each other is thus an indispensablefeature of the PHARE programme as a whole.

Documents

PHARE Ground Human Machine Interface (GHMI) project ...€¦ · PHARE programme and was responsible for the delivery of the Human Machine Interface (HMI) specifications. An international