Today s Operations Task Analysis

Transcription

1 Today s Operations Task Analysis Document information EC project title EPISODE 3 EC project N EPISODE 3 WBS WP Document Name Today s Operations Task Analysis - Deliverable ID/ Doc ID D Version 1.01 Version date Status Approved Owner of the document Rachael Gordon and Marie Fitzpatrick EEC Contributing partners NATS previous task analyses provided Page 1 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

2 DOCUMENT CONTROL Approval Role Organisation Name Version Date & signature Document owner Work Package leader Quality Coordinator Management cell Project Coordinator ERC ERC ERC ERC Rachael Gordon Andreas Tautz Henry Ly Validation cell Philippe Leplae Edition history Edition Nº Date Status Author(s) Justification - Could be a reference to a review form or a comment sheet /06/2007 Approved Rachael Gordon Approved Marie Fitzpatrick /06/2009 Approved C Palazo Format changes Page 2 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

3 TABLE OF CONTENTS 1 EXECUTIVE SUMMARY INTRODUCTION PURPOSE OF THE DOCUMENT INTENDED AUDIENCE DOCUMENT STRUCTURE BACKGROUND GLOSSARY OF TERMS REFERENCES AND APPLICABLE DOCUMENTS PURPOSE OF THE TASK ANALYSES EN-ROUTE TASK ANALYSIS EN-ROUTE TASK ANALYSIS APPROACH Principles of the Task Analysis Approach Reference Material Generic Procedures and System Building the Hierarchical Task Analysis (HTA) The Aircraft Plan High Level Structure Task emphasis Task Properties Building the Tabular Task Analysis Verifying the Task Analysis EN-ROUTE TASK ANALYSIS Hierarchical Task Analysis En-route Tabular Task Analysis TOWER TASK ANALYSIS TOWER TASK ANALYSIS APPROACH Purpose of the Tower Task Analysis Method of the Tower Task Analysis TOWER TABULAR TASK ANALYSIS RESULTS...21 Page 3 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

4 1 EXECUTIVE SUMMARY These task analyses will serve as a baseline from which comparisons between the current and the future predicted ATCO tasks under the SESAR Conops can be made and hence changes to the operators roles identified. More specifically, these task analyses will be used to identify changes in the types of tasks being performed, the cognitive aspects of the tasks, task organisation as well as changes in the skills required by ATCOs to perform the tasks. These task analyses will enable us to gain understanding of the impact of the SESAR Conops on future ATCO roles/tasks/skills and help us to identify human factors issues that require further examination as part of the concept validation process. The purpose of this document is to describe the work that was undertaken to develop task analyses of current ATCOs roles in nominal situations for en-route, Terminal Manoeuvring Area (TMA) and tower. It is envisioned that if required a task analysis for the CFMU should also be undertaken. It is envisioned that the task analysis for the TMA will be completed by December, This document is intended for use by those employed within the EUROCONTROL agency and by Episode 3 partners in the validation of the SESAR CONOPS who have to investigate the impact that the SESAR Conops will have on the tasks of the actors in the ATM system. In particular, this will be useful for those partners involved in work packages 4 and 5 who are involved in Procedure and Roles Definition. The HTA reflects the procedural and cognitive processes. To permit this, the HTA distinguishes between tasks that take place for every aircraft, performed in a specific order, tasks that are performed continually or others that are performed after a specific trigger. Task Architect software has been used to develop the HTA. Initially each task will be defined by the following properties: Task Name; Task Plan how the subtasks are conducted; Operator who executes the task; Task Description; Task Reference the task number and name of the reference task, mainly used when calling the Information Acquisition and Processing Tasks from other tasks.; System Specific Task A Binary field to indicate if the task is specific to the system as defined or if totally generic. The Tabular Task Analysis (TTA) simply consists of the HTA output in tabular format, with more properties elaborated. The additional properties of interest include: Other actors involved; Task constraints; Task outputs; Information sources; Communication mechanisms employed. Various output formats, including high colour use have been used to best illustrate changes in key areas between current and future systems. Operational SMEs were regularly involved in reviewing the HTA and TTAs 2 INTRODUCTION 2.1 PURPOSE OF THE DOCUMENT The purpose of this document is to describe the work that was undertaken to develop task analyses of current ATCOs roles in nominal situations for en-route, Terminal Manoeuvring Area (TMA) and tower. It is envisioned that if required a task analysis for the CFMU should also be undertaken. It is envisioned that the task analysis for the TMA will be completed by December, Page 4 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

5 2.2 INTENDED AUDIENCE This document is intended for use by those employed within the EUROCONTROL agency and by Episode 3 partners in the validation of the Medium Term Concept of Operations who have to investigate the impact that the SESAR Conops will have on the tasks of the actors in the ATM system. In particular, this will be useful for those partners involved in work packages 4 and 5 who are involved in Procedure and Roles Definition. 2.3 DOCUMENT STRUCTURE The document has three remaining sections: In section 3, the purpose and use of the Task Analyses will be described. In section 4, the approach and results of the En-route Task Analysis is detailed. In section 5, the approach and results of the tower task analysis is provided. 2.4 BACKGROUND These task analyses will serve as a baseline from which comparisons between the current and the future predicted ATCO tasks under the SESAR Conops can be made and hence changes to the operators roles identified. More specifically, these task analyses will be used to identify changes in the types of tasks being performed, the cognitive aspects of the tasks, task organisation as well as changes in the skills required by ATCOs to perform the tasks. These task analyses will enable us to gain understanding of the impact of the SESAR Conops on future ATCO roles/tasks/skills and help us to identify human factors issues that require further examination as part of the concept validation process. 2.5 GLOSSARY OF TERMS Term Definition ATCO ATC TA HTA TTA SME CONOPS Air Traffic Controller Air Traffic Control Task Analysis Hierarchical Task Analysis Tabular Task Analysis Subject Matter Expert Concept of Operations 3 REFERENCES AND APPLICABLE DOCUMENTS Ref. Document Name Applicability [1] Episode3 proposal TBC Applicable [2] Kirwan, B. and Ainsworth, L.K. (1992) A guide to task analysis. London: Taylor and Francis Applicable [3] EEC Report. HUM.ET1.ST REP-02. Model of Cognitive Aspects of Air Traffic Control. Page 5 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

6 [4] EEC report. HUM.ET1.ST REP-04. Integrated task and job analysis of Air traffic controllers Phase 2 Task Analysis of En-route Controllers. [5] EEC Report. HUM.ET REP-05. Integrated task and job analysis of Air traffic controllers Phase 3: Baseline Reference of Air Traffic Controller Tasks and Cognitive Processes in the ECAC Area. [6] Cognitive Task Analysis of Expertise in Air Traffic Control. Seamster, T.L, et al. (1993). The international journal of aviation psychology. [7] Cognitive Task Analysis of En-Route Air Traffic Control: Model Extension and validation. Redding et al. (1992). Report to the FAA. McLean, VA :Human Technology, Inc. (ERIC Document Reproduction No. ED ). [8] NATS NERC Task Analysis [9] MFF En-route Task Analysis, internal project document [10] COSPACE ASAS Task Analysis, internal project document [11] GTG WP4 Controllers Roles and Tasks, internal project document 4 PURPOSE OF THE TASK ANALYSES The purpose of the task analyses are to support in the following activities:- Identify the changing role of the ATCO in differing environments (e.g en-route compared to the tower) and in terms of current and future ATC concepts and systems (e.g current day operations compared to those envisaged under the SESAR Concept of Operations (CONOPS) to be validated during Episode 3). Map the SESAR CONOPS support and automation systems to controller tasks to provide a global understanding of where support is and is not provided. Permit the identification of psychological and cognitive changes in operation, feeding future work in those areas. Provide a reference and common understanding of operations. Educate on ATCO tasks, leading to better understanding and increased harmony between technical & validation teams and controller operations. 5 EN-ROUTE TASK ANALYSIS 5.1 EN-ROUTE TASK ANALYSIS APPROACH Principles of the Task Analysis Approach The task analysis approach is guided by the following principles:- Page 6 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

7 Based on nominal operations in a nominal environment. operations will not be analysed. Emergency or degraded Generic as possible. Unlike conventional task analyses, this approach is not based on a specific system, a specific set of procedures in a specific airspace. Instead is will amalgamate existing and future systems and procedures and seek to maximise detail without becoming overly specific at the high level stages. Defined specificity. When the task analysis reaches a level where a specific system object is required (e.g a FPS), it shall be made based upon a predefined generic system representative of typical existing and future ATC systems. Operationally driven. User focused approach around the ATCO. Should be of interest and comprehendible by operational staff. Therefore is will seek to use the language and reflect the structure common to ATCO procedures. Multi-layer level of comprehension. The analysis should be understandable at the high level without the necessity to delve into lower levels of detail unless specifically required Reference Material The Analysis draws upon work previously performed, listed in section 3 above. From performed analysis of the above material it is clear that each analysis is essentially correct, however each varies significantly in style. The more operational and specific task analyses are those concerned with operations of actual existing systems, e.g NERC, the COSPACE and MFF simulations. The cognitive studies are more generic, speaking less of procedures and more of mental modelling and cognitive activities. Each type of approach therefore misses information of attention to certain others areas and are therefore not regarded as fully satisfactory. The approach proposed here aims to merge the operational and cognitive approaches to produce an analysis, principally operationally driven, but that also tries to maximise the inclusion of the cognitive processes. The analysis will be in the form of a Hierarchal and Tabular Task Analysis (HTA & TTA) with emphasis on completing the HTA prior to deriving the TTA and expanding it Generic Procedures and System Generic procedures and the generic functionality of an ATC system shall be defined as part of the analysis. High-level procedures are somewhat easier to define and a common ATC method easier to agree. Lower-level procedures or tasks concerning interaction with a system are much harder to define without reference to a specific system. It is therefore essential that a typical ATC system and its functionality are defined prior or in parallel to the task analysis. This system will be verified typical via peer and SME review, based upon knowledge of existing ATC operations and understanding of future systems required by the SESAR CONOPS Building the Hierarchical Task Analysis (HTA) The HTA reflects the procedural and cognitive processes. To permit this, the HTA will distinguish between tasks that take place for every aircraft, performed in a specific order, tasks that are performed continually or others that are performed after a specific trigger. Page 7 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

8 Task Architect software has been used to develop the HTA The Aircraft Plan The key component of the task analysis is the Aircraft Plan. This is the plan the controller(s) have for a specific aircraft and should not be confused with the Flight Plan, which is the plan the Aircraft has for itself until overridden by ATC. The analysis sees the development of an Aircraft Plan of operations that starts off coarse and imprecise, but is continually refined in a piecewise fashion before execution. The plan is totally dynamic and represents, in varying degrees of precision, everything the controller intends to do with an aircraft, from routine clearances to detailed conflict resolutions. In the simplest sense, the plan starts off as a route from entry to exit, considering no other traffic or quality of service improvements. Bear in mind that the plan is not homogeneous in detail. It is perfectly reasonable that the entry detail is greater than the exit detail when an aircraft is first processed. Later the plan is revised to include conflict and quality of service solutions via procedural 'planning' of the flight through the sector and executive management of the flight through the sector based upon mainly continuous processes of conflict searching and providing quality of service. The Aircraft Plan is the object that is continuously being refined throughout the period of control by controller detection of and/or reaction to external events High Level Structure The following table outlines the high-level HTA structure to be used. Procedural Tasks Continuous Tasks Reactive Tasks Information Acquisition and Processing Tasks Tasks that take place once for each aircraft in a specific order as it transits the airspace. These types of tasks will mostly reflect the procedural control methods used, e.g Detect Flight, Plan Flight In, Plan Flight Out, Execute the Aircraft Plan etc. Procedural tasks are identified by assuming only one aircraft exists in the system and simply recording the sequential tasks performed on it. These are tasks that take place continuously whilst no other task is being performed. They represent key controlling tasks such as conflict searching and conformance monitoring. Output from these tasks is usually a refinement or change to the Aircraft Plan (e.g a conflict solution), which is then appropriately executed. Theses tasks are external events not under the control of the controller, e.g coordinations from adjacent sectors, SNET and other system alerts. These tasks as invoked when certain triggers are made. These set of tasks are equivalent to the programming notion of Functions or Subroutines. They are information acquisition and processing orientated and are frequently referenced or called as sub-tasks from the above tasks. An example would be Get Instantaneous Aircraft Position. Making multiple references in this way permits a low level of detail in the above tasks whilst keep the HTA size to a minimum. These very tasks are also indeed those that are regularly system specific, e.g how to get a certain type of information from the ATC system. Therefore in concentrating them into one area, the majority of system specific actions can be contained in one place, thus the HTA remains easily adaptable to changes to the system definition. Page 8 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

9 5.1.7 Task emphasis Since the main objective of the analysis is to permit a comparison with a similar analysis perform for the future SESAR CONOPS derived operations, it is wise to emphasise tasks that are anticipated to change by the greatest degree. This requires some future knowledge of the future concept and recognition of the fundamental differences to current operations. With this understanding the HTA will develop with biases towards tasks of interest. The HTA will also be flexible enough to permit a retrospective expansion of detail should it be desired in the future Task Properties Initially each task will be defined by the following properties: Task Name Task Plan how the subtasks are conducted Operator who executes the task Task Description Task Reference the task number and name of the reference task, mainly used when calling the Information Acquisition and Processing Tasks from other tasks. System Specific Task A Binary field to indicate if the task is specific to the system as defined or if totally generic Building the Tabular Task Analysis The Tabular Task Analysis (TTA) simply consists of the HTA output in tabular format, with more properties elaborated. The additional properties of interest include: Other actors involved Task constraints Task outputs Information sources Communication mechanisms employed Task Architect software and MS Excel have been used to develop the TTA. Various output formats, including high colour use have been used to best illustrate changes in key areas between current and future systems. Page 9 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

10 Verifying the Task Analysis Operational SMEs were regularly involved in reviewing the HTA and TTA. The development process is somewhat iterative and therefore multiple revisions of the HTA and TTA were undertaken as styles and emphasis matured. Page 10 of 30 Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

11 5.2 EN-ROUTE TASK ANALYSIS Hierarchical Task Analysis Page 11 of 30

12 5.2.2 En-route Tabular Task Analysis Task Detect Planned Flight Identify Entry/Transit/Exit Problems Find Entry/Transit/Exit Solutions Verify Entry/Transit/Exit Solutions Choose Best Entry/Transit/Exit Solution Warn of Unsolved Entry/Transit/Exit Problems Identify Quality of Service Improvement Sub Tasks Detect Aircraft Position Understand Aircraft's Routing, RFL and Destination Get Aircraft's Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Search for Interactions Understand Aircraft Capability Entry Solutions Consider a Change in Entry Level Solution Consider a Change in Entry Point Solution Transit Solutions Consider a Change in Cruise Level Solution Exit Solutions Consider a Change in Exit Level Solution Consider a Change in Exit Point Solution Get Aircraft's New Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Search for Interactions Consider Safety Assurance Consider ATC Constraints Consider Quality of Service Level Consider Level of Workload Verbally Inform EC Mark FPS Cock FPS Highlight Aircraft Label Consider a More Expeditious Entry Point Consider a More Efficient Entry Level Consider a More Expeditious Exit Point Consider a More Expeditious Exit Level Main Actor PC PC PC PC PC Other Actors PC EC PC Task Constraints ETOs only provided at significant fixes ETOs have large tolerances margins (3mins) Solutions restricted to a change in :- PEL NPT Cruise Level XFL XPT ETO changes as a result of the solution are estimated manually ETOs only provided at significant fixes ETOs have large tolerances margins (3mins) Large ETO margins result in coarse solutions Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required Solutions restricted to a change in :- PEL NPT XFL XPT Task Output First instantiation of the aircraft's plan. Knowledge of aircraft location, and planned intentions Knowledge of interactions with other aircraft One or more problem solutions One or more verified problem solutions One problem solution to be implemented, usually via co-ordination A verbal and/or written problem warning One or more QoS improvements Info Sources RPVD, FPS, E-FP RPVD, FPS, E-FP RPVD, FPS, E-FP, 'problem solutions library' RPVD, FPS, E-FP Comms Systems?? FPS, TDB RPVD, FPS, E-FP, 'QoS improvements library' Verbal, Written Description Initial detection the expectation of the flight by the PC. This does not necessarily correspond to a radar identification, but can be information (FPS, E-FP) as well. Look for 'problems' around entry and exit points, and around significant transit points. Solutions to problems are searched for, before the best solution chosen. Bear in mind that solutions are rarely mutually exclusive. E.g. a change in entry level may result in having to change the exit level as well. Solutions have to be checked if they work and in case they introduce other problems. In practice this takes places at the same time as developing the solutions. If multiple solutions are available then selection has to take place. Selection must consider various criteria, e.g. What is the best solution? Best is terms of QoS, Workload, Safety etc. Note that a controller normally has a library of typical solutions to employ for typical problems. Therefore the explicit consideration of best solution factors doesn't always take place, as they are already known are part of the standard solution. Problems without solution are communicated to the EC Look for QoS improvements around entry and exit points. Similar to problems, at this stage, this task is more likely to result in the planning of entry changes that of exit changes. Page 12 of 30

13 Verify Quality of Service Improvement Choose Best Quality of Service Improvement Co-ordinate Change in Entry Conditions Monitor Incoming Traffic Get Aircraft's New Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Search for Interactions Consider Safety Assurance Consider ATC Constraints Consider Quality of Service Level Consider Level of Workload Make Co-ordination Proposal Propose New Entry Point Propose New Entry Level Receive Response Assess Response Identify Any Resulting Entry/Transit/Exit Problems (ref) Co-ordination Agreement Reached Update FPS Inform EC Co-ordination Agreement Not Reached Warn Unsolved of Entry/Transit/Exit Problems (ref) Get Aircraft Location Get Aircraft Level PC PC PC PC(-) EC ETO changes as a result of the QoS improvement are estimated manually ETOs only provided at significant fixes ETOs have large tolerances margins (3mins) Large ETO margins result in coarse solutions Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required Solutions restricted to a change in :- PEL NPT One or more QoS verified improvements One QoS improvement to be implemented via coordination An agreed and recorded change in entry conditions (PEL and/or NPT) No agreement and therefore a subsequent warning of the unsolved entry problem (see previous task) A general appreciation of incoming traffic, enough to anticipate when call-in will take place RPVD, FPS, E-FP?? FPS RPVD Verbally, Telephone, Written Solutions have to be checked in case they introduce other problems. In practice this takes places at the same time as developing the solutions. If multiple solutions are available then selection has to take place. Selection must consider various criteria, e.g. What is the best solution? Best is terms of QoS, Workload, Safety etc. Note that a controller normally has a library of typical solutions to employ for typical problems. Therefore the explicit consideration of best solution factors doesn't always take place, as they are already known are part of the standard solution. This task is likely to occur to implement entry solutions that require a co-ordination. Exit co-ordination does not take place at this time, but occurs later when the achievement of XFL is better assessed by the EC and when the aircraft is closer to the sector exit. This task represents the EC having an awareness of incoming traffic. The awareness is not full, with a minimum the location of the traffic understood. The task is really to provide anticipation of the call-in Receive Aircraft Calling-In Detect Aircraft Understand Previous Planning Check/Refine Previous Planning Reply to Aircraft Confirm Aircraft Location Confirm Aircraft Level Confirm Aircraft's Current Clearance Confirm Aircraft's Routing, RFL and Destination Changed Entry Conditions (level, point) Problem Warnings Planned Cruising Level Planned Exit Conditions Initial Conflict Search - Conflict Management (ref) Look for Quality of Service Improvements - Maximise Quality of Service (ref) Acknowledge Aircraft Issue Initial Clearance - Execute Aircraft's Plan (ref) EC Pilot EC EC PC EC EC Pilot see Conflict Management and Maximise QoS Tasks Knowledge of a new aircraft on frequency. Knowledge of reported aircraft status Knowledge of the aircraft location, level, current clearance and intended routing Transfer of the PC's aircraft's plan to the EC Knowledge of problem warnings Refinement of problems into conflicts (or not), new conflicts, new QoS improvements Aircraft receives identification confirmation. Initial clearance may be given Pilot RPVD, Reported information FPS, PC see Conflict Management and Maximise QoS Tasks R/T Written, Verbal see Conflict Management and Maximise QoS Tasks R/T Pilot calls ATC, report in with position and current clearance EC assimilates aircraft. Where is the aircraft? What's it's current state. What's it's currently cleared too. Then where is it going? EC learns of the exiting planning. What has the PC already seen and planned for this flight? EC double checks the PC's plan and looks for improvements of his/her own. Represents the first Conflict Management and Maximise Quality of Service task the EC performs. Reply to Aircraft, confirm positive identification and give initial clearance if required. The initial clearance represents the first of the execution tasks described in Execute Aircraft's Plan (see later) Page 13 of 30

14 Record on Frequency Mark FPS Update Label EC A record that the aircraft is on frequency FPS, TDB Written EC notes the aircraft is on frequency Monitor Aircraft's Plan For Action Points EC PC Knowledge that a previously planned action is now due to be implemented Memory, FPS Periodically check the Aircraft plan to see if an action is due to be performed. This task is closely related to the Task Switching tasks as described in the EEC CTA. Here we do not describe exactly how the plan is monitored. Examples of actions are, clearances when clear of ATC constraints, clearance to implement conflict solutions and QoS improvements, clearances to achieve the plan exit conditions, emergency response clearances, planned and request co-ordinations etc. The process is sometimes a conscious and sometimes not. The main actor is the EC, however the PC can frequently act as a prompt Request Information from Aircraft Non Conformance Rational Estimates Aircraft Reports Aircraft State Aircraft Capability EC Pilot Immediate knowledge of desired information (e.g. aircraft state, aircraft capability, ETO estimate, non-conformance rationale) Requirement for the pilot to report an event Pilot R/T When a controller wants more information he/she will ask the aircraft to report it immediately or when it occurs, e.g. report current heading, report passing etc Provide Information to Aircraft Issue Instructions Co-ordinate Change in Exit Conditions Turbulence Reports Traffic Information Conflict Resolution Instructions (headings, speeds, levels) Conformance Correction Instructions (directs, headings, speeds, levels) Quality of Service Improvement Instructions (directs, good levels, free speeds) Instructions to Meet ATC Constraints (levels, speeds) Responses to Aircraft Requests Verify Readback Update FPS Make Co-ordination Proposal Propose New Exit Point Propose New Exit Level Receive Response Identify Any Resulting Entry/Transit/Exit Problems (ref) Co-ordination Agreement Reached Update FPS Co-ordination Agreement Not Reached Warn Unsolved of Entry/Transit/Exit Problems (ref) EC Pilot EC Pilot PC PC(+) Solutions restricted to a change in :- XFL XPT Useful (in terms of QoS) context information is provided to the pilot. May results in further requests The passing and verification of an instruction from ATC to the Pilot. A record of the given instruction An agreed and recorded change in entry conditions (XFL and/or XPT) No agreement and therefore a subsequent warning of the unsolved exit problem (see previous task) Memory, RPVD FPS FPS R/T Written, R/T Verbal, Telephone, Written These tasks provide optional information to aircraft, normally as part of a good QoS, e.g. turbulence reports and context traffic information Issue instructions in accordance to the aircraft's plan. Instruction types are:- Conflict Resolution Instructions (headings, speeds, levels) Conformance Correction Instructions (directs, headings, speeds, levels) Quality of Service Improvement Instructions (directs, good levels, free speeds) Instructions to Meet ATC Constraints (levels, speeds) Instructions in response to Aircraft Requests This is where the time for co-ordinating a previously planned (initially by the PC, but perhaps then refined by the EC) exit condition occurs. The task is likely to occur after sector entry and during sector transit Request a Entry/Exit Radar Handover Make Radar Handover Proposal Request New Exit/Entry Heading Request New Exit/Entry Level Request New Exit/Entry Speed Receive Response Agree on Handover Conditions Update FPS Disagree on Handover Conditions EC EC(-), EC(+) Solutions restricted to a change in :- XFL XPT or a :- specific heading specific speed An agreed and recorded set of radar handover conditions, usually implemented ASAP. No agreement and therefore a remaining conflict FPS Verbally, Telephone, Written This is where the EC performs a previously planned radar handover, either for entry or exit. Due to the nature of radar handovers the time between the conception and execution is small, sometimes immediate. Nevertheless it is still thought of as part of the EC Aircraft planning Forward New Exit ETO PC PC(+) The next sector is provided with a change in exit ETO to subsequently revise their FPSs Verbally, Telephone Having been asked by the EC, the PC verbally informs the next sector of a ETO revision Page 14 of 30

15 3.1.5 Transfer Aircraft Determine if Aircraft Can Be Transferred Final Conflict Check - Conflict Management (ref) Check Exit Conditions Will Be Reached - Assess Achievement of Exit Conditions (ref) Instruct Aircraft to Change Frequency Verify Readback Update FPS EC Pilot The transfer of a clean aircraft at its agree exit conditions The passing and verification of a frequency change instruction from ATC to the Pilot. A record of the given instruction FPS, TDB R/T ATC check aircraft is clean and meets its planned exit before transferring the aircraft to the next sector Identify Suspected Conflicts EC PC A suspected conflict, to be subsequently investigated Memory, RPVD, FPS, E-FS Verbal A task where the controller first identifies initially conflicts by identifying common scenarios where conflicts occur. For example, the simple position of two aircraft on two well known routes is enough, with experience, to make the controller suspect a later conflict. Suspicious at this stage are then investigated in more detail. The PC can equally well perform this task Search Aircrafts Plans for Conflicts Get Aircraft's Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Extrapolate Aircraft Positions Between Waypoints Search for Interactions EC PC Large ETO margins mean only coarse conflicts can be identified, eventually requiring refinement by using the radar. Suspected conflict confirmed via FPS information. FPS Verbal, Written This is where the EC (and PC) mainly use the FPS to search for conflicts, some of which will have already been previously identified by the PC or may have been identified as possible or suspected conflicts by the EC. The task is very similar to the PC 'problem' searching tasks, except more accuracy is pursued here. The task often confirms a previous suspicion and then triggers the next type of conflict detection, using the radar to find radar more conflict detail. The PC can equally well perform this task Search Radar for Conflicts Linearly Extrapolate Aircraft Positions Search for Interactions EC Identification of a radar conflict Memory, RPVD (speed vectors, range and bearing) Aircraft positions are simply projected forward in time to ascertain short-term future positions. This is done mentally and quite frequently via basic RPVD tools such as speed vectors and range and bearing. System extrapolation however is limited by being based on current performance parameters. Therefore the controller must mentally adjust the projection to take account of planned route, level and speed changes. Therefore the rage of this type of extrapolation will vary Request Information (Aircraft State Info) from Aircraft [Plan and Execute Now] EC See Request Information from Aircraft task See Request Information from Aircraft task Knowledge of aircraft state thought relevant to the conflict in question See Request Information from Aircraft task See Request Information from Aircraft task The EC here requires further information in order to verify a suspected conflict. The information required is either unknown or of not enough quality to make a conflict detection. The EC therefore contacts the aircraft directly and requests aircraft state information. Because this task is performed as part of the conflict detection task, the information request is planned and actioned immediately so to not break-up the conflict detection task Postpone Conflict Solution Consider Workload EC Knowledge of a suspected conflict and the required to monitor its evolution in the future. A conflict may be detected that at the present time is marginal with respect to a loss of separation. Therefore the EC may decide to postpone solving the conflict and prefer to wait until more detail can be ascertained. He/she therefore monitors this conflict by continuously detecting and analysing it in the future. The amount of conflict monitoring is greatly affected by the available workload the EC has in the future. In some cases it may be simpler to solve a suspected conflict rather than have to monitor and come back to it in the future Page 15 of 30

16 Find Conflict Solutions Understand Aircraft Capability Request Information (Aircraft Capability) from Aircraft [Plan and Execute Now] Plan a Vectoring Solution Plan Routing Solution Plan Speed Solution Plan Level Solution EC Pilot Solutions can be one of more of the following:- Vectoring Routing Speed Level One or more conflict solutions RPVD, FPS, E-FP, 'problem solutions library', Pilot R/T Solutions to conflicts are searched for, before the best solution chosen. At this stage the EC can use his/her 'solutions library' as well as search for novel solutions. Aircraft capability information is recalled, and when further required, it is asked for. Note in reality the finding and verification of problems are done concurrently Verify Solutions Linearly Extrapolate Conflict Solution Linearly Extrapolate Other Aircraft Positions Get Aircraft's What-if Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Search for Interactions EC One or more verified conflict solutions Memory, FPS, RPVD (speed vectors, range and bearing) The conflict solution must be verified to see if it solves the conflict and if it creates other problems. In practice this task takes place at the same time as planning the solutions Choose Best Solution Consider Safety Assurance Consider ATC Constraints Consider Quality of Service Level Consider Level of Workload EC Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required One conflict solution to be implemented, usually fairly immediately?? If multiple solutions are available then selection has to take place. Selection must consider various criteria, e.g What is the best solution? Best is terms of QoS, Workload, Safety etc. Note that a controller normally has a library of typical solutions to employ for typical problems. Therefore the explicit consideration of best solution factors doesn't always take place, as they are already known are part of the standard solution Update Aircraft's Plan with Conflict Solution Actions EC PC Aircraft's plan incorporating newly added conflict solution actions, usually to be implemented fairly immediately. Triggering of Exit Conditions Assessment task. Knowledge of the latest aircraft state (location, level & speed) The result of the conflict identification and solution process is an update to the aircraft plan, to be implemented when appropriate (which is not necessarily instantaneously). If exit conditions are affected, then the relevant exit assessment tasks are triggered (see later) Get Current Aircraft State Get Aircraft Location Get Aircraft Level Get Aircraft Speed EC PC RPVD Understand the real-time status information of the Aircraft. This usually consists of Location, Level & Speed. The PC may perform this task Recall Aircraft Plan Get Aircraft's Routing, RFL and Destination Get Aircraft's Current Clearance EC PC Knowledge of the aircrafts flight plan and any issued instructions that have caused deviation from it. FPS Written Recall what the aircraft should be doing. This is a combination of the flight plan and any additional instructions that have been issued. The PC may perform this task Check Conformance to Aircraft's Plan Check Conformance to Flight Plan Check Conformance to Instructions EC PC Identification of a nonconformance, in terms of deviation from the flight plan or from issued instructions?? Is the aircraft's current state consistent with that expected from the current understanding of the Aircraft's Plan? The PC may perform this task Search and Solve Non-Conformant State For Conflicts - Conflict Management (ref) EC see Conflict Management Task A updated aircraft plan to solve any conflicts caused by the non-conformance see Conflict Management Task see Conflict Management Task If the aircraft is found non-conformant the first reaction is to check if the non-conformance is causing a conflict and find a solution to it. The solution of course could turn out to be the original instruction, but equally well may now have evolved into another instruction Request Information (Non Conformance Rational) from Aircraft [Plan and Execute Now] EC See Request Information from Aircraft task See Request Information from Aircraft task Knowledge of the pilot rationale behind a detected nonconformance See Request Information from Aircraft task See Request Information from Aircraft task The aircraft is non-conformant in a fashion the controller feels is off particular safety concern, therefore the controller will ask for the reason for the non-conformance. Because this task is performed as part of the conformance management task, the information request is planned and actioned immediately so to not break-up the bigger task. Page 16 of 30

17 Correct Non- Conformance Plan Reissuing the Instruction Being Non-Conformed With Plan reissuing Appropriate Routing Instructions EC A conformance corrections action(s) to be implemented when appropriate, usually fairly immediately. FPS, E-FP, Memory This task deals with the correction of non-conflictual nonconformances. Note - If the non-conformance did result in a conflict it would have been solved when checking the non-conformance for conflicts. These less urgent nonconflictual corrections are usually made by simply restating the instruction previously given, or routing expected. Occasionally, such as when aircraft attempt to cut corners and there's no resulting danger, the controller may decide not to correct the non-conformance and let it go Update Aircraft's Plan With Non- Conformance Correction Identify Quality of Service Improvement Verify Quality of Service Improvement Choose Best Quality of Service Solution Plan Asking for an Aircraft Report Consider a More Expeditious Sector Routing Consider a More Efficient Vertical Profile Consider a More Efficient Speed Profile Consider a More Expeditious Exit Point Consider a More Efficient Exit Level Consider Issuing Turbulence Warning Consider Issuing Context Traffic Information Linearly Extrapolate What-if Aircraft Position Linearly Extrapolate Other Aircraft Positions Get Aircraft's What-if Position, Level and Time at Waypoints Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints Search for Interactions Consider Safety Assurance Consider ATC Constraints Consider Quality of Service Level Consider Level of Workload EC EC EC EC EC Solutions restricted are :- More expeditious routing and XPT More efficient vertical profile and XFL More efficient speed profile Providing turbulence warning Providing context traffic information Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required Aircraft's plan incorporating newly added conformance correction actions, usually to be implemented fairly immediately. One or more QoS improvements One or more QoS verified improvements RPVD, FPS, 'QoS improvements library' Memory, FPS, RPVD (speed vectors, range and bearing) One QoS improvement.?? A planned reporting to later trigger a QoS improvement RPVD, FPS, 'QoS improvements library' The result of the conformance correction process is an update to the aircraft plan, to be implemented when appropriate (which is not necessarily instantaneously). Look for QoS improvements from aircraft position, through transit to the exit. QoS improvements have to be checked in case they introduce other problems. In practice this takes places at the same time as developing the solutions. If multiple solutions are available then selection has to take place. Selection must consider various criteria, e.g What is the best solution? Best is terms of QoS, Workload, Safety etc. Note that a controller normally has a library of typical solutions to employ for typical problems. Therefore the explicit consideration of best solution factors doesn't always take place, as they are already known are part of the standard solution. Here the EC has decided on a QoS improvement and may additionally decide that an aircraft report would be useful to trigger the improvement. This request of the report is therefore planned and usually executed immediately Update Aircraft's Plan with Quality of Service Improvements EC Aircraft's plan incorporating QoS improvement actions. The result of the QoS improvement process is an update to the aircraft plan, to be implemented when appropriate (which is not necessarily instantaneously). The plan could simply be to issue an instruction, but may be more complex and require co-ordination Page 17 of 30

18 Assess Achievement of Exit Point and Level Recall Exit Conditions Identify if Conflict Solutions Prohibit Achieving Exit Conditions Search Aircraft's Plan for Conflict Solutions Identify if Aircraft Vertical Performance Prohibits Achieving Exit Level Linearly Extrapolate Aircraft Vertical Position Plan New Exit Conditions Recall Exit Conditions From The Conflict Solution Choose a New Exit Level Plan New Level Linearly Extrapolate What-if Aircraft Position Verify New Level Linearly Extrapolate What-if Aircraft Position Linearly Extrapolate Other Aircraft Positions Search for Interactions Choose Best Level Consider Safety Assurance Consider Quality of Service Level Choose Type of Co-ordination Plan a Regular Exit Co-ordination Plan a Exit Radar Handover EC PC Possible revised (via coordination or radar handover) exit conditions due to a conflict solution or performance limitation. Memory, FPS, RPVD (speed vectors, range and bearing) This is the EC task where he/she checks the exit point and level previously planned will be achieved. This may not be the case due to a conflict solution having to change exit conditions or the aircraft physically not being able to achieve the exit. In both cases appropriate exit coordination or radar handover requests are assessed and planned Assess Achievement of Exit ETO Recall Original Exit ETO Determine New Exit ETO Request Information (Estimates) from Aircraft [Plan and Execute Now] Plan to Forward a New ETO EC Pilot PC Possible plan to send an ETO revision to the downstream sector RPVD, FPS See Request Information from Aircraft task See Request Information from Aircraft task This is the task where the EC is responsible for detecting and the PC for phoning on exit/entry estimates if they change by more than a certain amount (normally 3 mins). This task may trigger (as part of the task), the Request Information (Estimate) task. This is planned and executed immediately are part of the bigger task Workload Monitoring React to Unsolved Entry Problems Respond to Safety Net Alerts Consider Current Workload Level Consider Future Workload Level Plan Co-ordinations to Minimise Future Workload Inform Supervisor Detect Entering Aircraft With Problem - Detect Aircraft (ref) Confirm and Solve Entry Conflict - Conflict Management (ref) Identify if Entry Conflict Solution Requires a Change in Entry Conditions Search Aircraft's Plan for Conflict Solution Plan and Perform an Entry Radar Handover Refine Conflict Detail Linearly Extrapolate Aircraft Positions Search for Interactions Solve Conflict (ref) Update Aircraft's Plan with Conflict Solution Actions EC, PC SUP EC EC See Solve Conflict sub-tasks See Solve Conflict sub-tasks Knowledge of current and future workload as a result of incoming traffic and plans made upon it. Planned solutions to entry problem. Possible entry radar handover planning See Update Aircraft's Plan with Conflict Solution Actions See Assume Aircraft subtasks 3&5 RPVD, TDB See Solve Conflict subtasks Verbal See Assume Aircraft subtasks 3&5 Self-analysis of workload. Used as input to sector supervisory decisions regarding sector config and flow restrictions etc. Input also used in the consideration problem, QoS and conflict solutions. E.g a busy controller would avoid actions requiring excess This is where the PC cannot solve an entry problem and alerts the EC to it prior to the EC's normal detection and consideration of the flight. In effect therefore EC assimilates the flight earlier than normal, thus performing earlier conflict detection and solution that may require a radar handover. STCA and MSAW alert the controller to an immanent conflict. The controller responds by solving the conflicts as if it detected by him/her Page 18 of 30