today’s operations task analysis - eurocontrol · 2019-02-18 · episode 3 d2.4.4-05 today’s...

Episode 3

D2.4.4-05 Today’s Task Analysis –

Human Factor Assessment

Date: 30-06-2007

N°: 1.01

Status: Approved

of 30

Issued by the Episode 3 consortium for the Episode 3 project co-funded by the European Commission and Episode 3 consortium.

Today’s Operations Task Analysis

Document information

EC project title EPISODE 3

EC project N° 037106

EPISODE 3 WBS WP 2.4.4

Document Name Today’s Operations Task Analysis - Human Factor Assessment

Deliverable ID/ Doc ID D2.4.4-05

Version 1.01

Version date 30-06-2007

Status Approved

Owner of the document

Rachael Gordon and Marie Fitzpatrick EEC

Contributing partners

NATS – previous task analyses provided

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


DOCUMENT CONTROL

Approval

Role Organisation Name Version Date & signature

Document owner

ERC Rachael Gordon

Work Package leader

ERC Andreas Tautz

Quality Coordinator

ERC Henry Ly

Management cell

Validation cell

Project Coordinator

ERC Philippe Leplae

Edition history

Edition Nº Date Status Author(s) Justification - Could be a

reference to a review form or a comment sheet

1.00 30/06/2007 Approved Rachael Gordon

Marie Fitzpatrick

Approved

1.01 5/06/2009 Approved C Palazo Format changes

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


TABLE OF CONTENTS

1 EXECUTIVE SUMMARY ...................................................................................................4

2 INTRODUCTION................................................................................................................4

2.1 PURPOSE OF THE DOCUMENT........................................................................................4 2.2 INTENDED AUDIENCE ....................................................................................................5 2.3 DOCUMENT STRUCTURE ...............................................................................................5 2.4 BACKGROUND ..............................................................................................................5 2.5 GLOSSARY OF TERMS...................................................................................................5

3 REFERENCES AND APPLICABLE DOCUMENTS ................ .........................................5

4 PURPOSE OF THE TASK ANALYSES....................... .....................................................6

5 EN-ROUTE TASK ANALYSIS ............................. .............................................................6

5.1 EN-ROUTE TASK ANALYSIS APPROACH..........................................................................6 5.1.1 Principles of the Task Analysis Approach..........................................................6 5.1.2 Reference Material .............................................................................................7 5.1.3 Generic Procedures and System .......................................................................7 5.1.4 Building the Hierarchical Task Analysis (HTA) ..................................................7 5.1.5 The Aircraft Plan.................................................................................................8 5.1.6 High Level Structure...........................................................................................8 5.1.7 Task emphasis ...................................................................................................9 5.1.8 Task Properties ..................................................................................................9 5.1.9 Building the Tabular Task Analysis ....................................................................9 5.1.10 Verifying the Task Analysis ..............................................................................10

5.2 EN-ROUTE TASK ANALYSIS .........................................................................................11 5.2.1 Hierarchical Task Analysis ...............................................................................11 5.2.2 En-route Tabular Task Analysis .......................................................................12

6 TOWER TASK ANALYSIS................................ ..............................................................20

6.1 TOWER TASK ANALYSIS APPROACH ............................................................................20 6.1.1 Purpose of the Tower Task Analysis................................................................20 6.1.2 Method of the Tower Task Analysis .................................................................20

6.2 TOWER TABULAR TASK ANALYSIS RESULTS.................................................................21

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


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, 2007.

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, 2007.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


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 Air Traffic Controller

ATC Air Traffic Control

TA Task Analysis

HTA Hierarchical Task Analysis

TTA Tabular Task Analysis

SME Subject Matter Expert

CONOPS 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.ST01.1000-REP-02. Model of Cognitive Aspects of Air Traffic Control.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


[4] EEC report. HUM.ET1.ST01.1000-REP-04. Integrated task and job analysis of Air traffic controllers – Phase 2 Task Analysis of En-route Controllers.

[5] EEC Report. HUM.ET1.1000-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. ED340 848).

[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

5.1.1 Principles of the Task Analysis Approach

The task analysis approach is guided by the following principles:-

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


• Based on nominal operations in a nominal environment. Emergency or degraded operations will not be analysed.

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

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

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

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

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


Task Architect software has been used to develop the HTA.

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

5.1.6 High Level Structure

The following table outlines the high-level HTA structure to be used.

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

Continuous Tasks

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.

Reactive Tasks Theses tasks are external events not under the control of the controller, e.g co-ordinations from adjacent sectors, SNET and other system alerts. These tasks as invoked when certain triggers are made.

Information Acquisition and Processing Tasks

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.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


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.

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

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

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


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

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


5.2 EN-ROUTE TASK ANALYSIS

5.2.1 Hierarchical Task Analysis

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


5.2.2 En-route Tabular Task Analysis

Task Sub Tasks Main Actor

Other Actors

Task Constraints Task Output

Info Sources

Comms Systems

Description

3.1.1 Detect Planned Flight

3.1.1.1 Detect Aircraft Position 3.1.1.2 Understand Aircraft's Routing, RFL and Destination

PC

First instantiation of the

aircraft's plan. Knowledge of aircraft location, and planned intentions

RPVD, FPS, E-FP None 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.

3.1.2.1.1 Identify Entry/Transit/Exit Problems

3.1.2.1.1.1 Get Aircraft's Position, Level and Time at Waypoints 3.1.2.1.1.2 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.1.2.1.1.3 Search for Interactions

PC

ETOs only provided at significant fixes ETOs have large tolerances margins (3mins)

Knowledge of interactions with other aircraft

RPVD, FPS, E-FP None Look for 'problems' around entry and exit points, and around significant transit points.

3.1.2.1.2 Find Entry/Transit/Exit Solutions

3.1.2.1.2.1 Understand Aircraft Capability 3.1.2.1.2.2 Entry Solutions 3.1.2.1.2.2.1 Consider a Change in Entry Level

Solution 3.1.2.1.2.2.2 Consider a Change in Entry Point Solution 3.1.2.1.2.3 Transit Solutions 3.1.2.1.2.3.1 Consider a Change in Cruise Level Solution 3.1.2.1.2.4 Exit Solutions 3.1.2.1.2.4.1 Consider a Change in Exit Level Solution 3.1.2.1.2.4.2 Consider a Change in Exit Point Solution

PC

Solutions restricted to a change in :- PEL

NPT Cruise Level XFL XPT

One or more problem solutions

RPVD, FPS, E-FP, 'problem solutions library'

None

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.

3.1.2.1.3 Verify Entry/Transit/Exit Solutions

3.1.2.1.3.1 Get Aircraft's New Position, Level and Time at Waypoints 3.1.2.1.3.2 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.1.2.1.3.3 Search for Interactions

PC

ETO changes as a result of the solution are estimated manually ETOs only provided at significant fixes ETOs have large tolerances margins (3mins)

One or more verified problem solutions

RPVD, FPS, E-FP None 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.

3.1.2.1.4 Choose Best Entry/Transit/Exit Solution

3.1.2.1.4.1 Consider Safety Assurance 3.1.2.1.4.2 Consider ATC Constraints 3.1.2.1.4.3 Consider Quality of Service Level 3.1.2.1.4.4 Consider Level of Workload

PC

Large ETO margins result in coarse solutions Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided

Level of workload required

One problem solution to be implemented, usually via co-ordination

?? None

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.

3.1.2.1.5 Warn of Unsolved Entry/Transit/Exit Problems

3.1.2.1.5.1 Verbally Inform EC 3.1.2.1.5.2 Mark FPS 3.1.2.1.5.3 Cock FPS 3.1.2.1.5.4 Highlight Aircraft Label

PC EC None A verbal and/or written problem warning

FPS, TDB Verbal, Written

Problems without solution are communicated to the EC

3.1.2.2.1 Identify Quality of Service Improvement

3.1.2.2.1.1 Consider a More Expeditious Entry Point 3.1.2.2.1.2 Consider a More Efficient Entry Level 3.1.2.2.1.3 Consider a More Expeditious Exit Point 3.1.2.2.1.4 Consider a More Expeditious Exit Level

PC

Solutions restricted to a change in :- PEL NPT XFL XPT

One or more QoS improvements

RPVD, FPS, E-FP, 'QoS improvements library'

None

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.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.1.2.2.2 Verify Quality of Service Improvement

3.1.2.2.2.1 Get Aircraft's New Position, Level and Time at Waypoints 3.1.2.2.2.2 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.1.2.2.2.3 Search for Interactions

PC

ETO changes as a result of the QoS improvement are estimated manually ETOs only provided at significant fixes ETOs have large tolerances margins (3mins)

One or more QoS verified improvements

RPVD, FPS, E-FP None Solutions have to be checked in case they introduce other problems. In practice this takes places at the same time as developing the solutions.

3.1.2.2.3 Choose Best Quality of Service Improvement


PC

Large ETO margins result in coarse solutions Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required

One QoS improvement to be implemented via co-ordination

?? None

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.

3.1.2.3 Co-ordinate Change in Entry Conditions

3.1.2.3.1 Make Co-ordination Proposal 3.1.2.3.1.1 Propose New Entry Point 3.1.2.3.1.2 Propose New Entry Level 3.1.2.3.2 Receive Response 3.1.2.3.3 Assess Response 3.1.2.3.3.1 Identify Any Resulting Entry/Transit/Exit Problems (ref) 3.1.2.3.4 Co-ordination Agreement Reached 3.1.2.3.4.1 Update FPS 3.1.2.3.4.2 Inform EC 3.1.2.3.5 Co-ordination Agreement Not Reached 3.1.2.3.5.1 Warn Unsolved of Entry/Transit/Exit Problems (ref)

PC PC(-)

Solutions restricted to a change in :- PEL NPT

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)

FPS Verbally, Telephone, Written

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.

3.1.3.1 Monitor Incoming Traffic

3.1.3.1.1 Get Aircraft Location 3.1.3.1.2 Get Aircraft Level

EC None

A general appreciation of incoming traffic, enough to anticipate when call-in will take place

RPVD None

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.

3.1.3.2 Receive Aircraft Calling-In

EC Pilot None

Knowledge of a new aircraft on frequency. Knowledge of reported aircraft status

Pilot R/T Pilot calls ATC, report in with position and current clearance

3.1.3.3 Detect Aircraft

3.1.3.3.1 Confirm Aircraft Location 3.1.3.3.2 Confirm Aircraft Level 3.1.3.3.3 Confirm Aircraft's Current Clearance 3.1.3.3.4 Confirm Aircraft's Routing, RFL and Destination

EC None

Knowledge of the aircraft location, level, current clearance and intended routing

RPVD, Reported information

None 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?

3.1.3.4 Understand Previous Planning

3.1.3.4.1 Changed Entry Conditions (level, point) 3.1.3.4.2 Problem Warnings 3.1.3.4.3 Planned Cruising Level 3.1.3.4.4 Planned Exit Conditions

EC PC None

Transfer of the PC's aircraft's plan to the EC Knowledge of problem warnings

FPS, PC Written, Verbal

EC learns of the exiting planning. What has the PC already seen and planned for this flight?

3.1.3.5 Check/Refine Previous Planning

3.1.3.5.1 Initial Conflict Search - Conflict Management (ref) 3.1.3.5.2 Look for Quality of Service Improvements - Maximise Quality of Service (ref)

EC

see Conflict Management and Maximise QoS Tasks

Refinement of problems into conflicts (or not), new conflicts, new QoS improvements



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.

3.1.3.6 Reply to Aircraft 3.1.3.6.1 Acknowledge Aircraft 3.1.3.6.2 Issue Initial Clearance - Execute Aircraft's Plan (ref)

EC Pilot None

Aircraft receives identification confirmation. Initial clearance may be given

None R/T

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)

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.1.3.7 Record on Frequency

3.1.3.7.1 Mark FPS 3.1.3.7.2 Update Label

EC None A record that the aircraft is on frequency

FPS, TDB Written EC notes the aircraft is on frequency

3.1.4.1 Monitor Aircraft's Plan For Action Points

EC PC None

Knowledge that a previously planned action is now due to be implemented

Memory, FPS None

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

3.1.4.2 Request Information from Aircraft

3.1.4.2.1 Non Conformance Rational 3.1.4.2.2 Estimates 3.1.4.2.3 Aircraft Reports 3.1.4.2.4 Aircraft State 3.1.4.2.5 Aircraft Capability

EC Pilot None

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.

3.1.4.3 Provide Information to Aircraft

3.1.4.3.1 Turbulence Reports 3.1.4.3.2 Traffic Information

EC Pilot None

Useful (in terms of QoS) context information is provided to the pilot. May results in further requests

Memory, RPVD R/T These tasks provide optional information to aircraft, normally as part of a good QoS, e.g. turbulence reports and context traffic information

3.1.4.4 Issue Instructions

3.1.4.4.1 Conflict Resolution Instructions (headings, speeds, levels) 3.1.4.4.2 Conformance Correction Instructions (directs, headings, speeds, levels) 3.1.4.4.3 Quality of Service Improvement Instructions (directs, good levels, free speeds) 3.1.4.4.4 Instructions to Meet ATC Constraints (levels, speeds) 3.1.4.4.5 Responses to Aircraft Requests 3.1.4.4.6 Verify Readback 3.1.4.4.7 Update FPS

EC Pilot None

The passing and verification of an instruction from ATC to the Pilot. A record of the given instruction

FPS Written, R/T

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

3.1.4.5 Co-ordinate Change in Exit Conditions

3.1.4.5.1 Make Co-ordination Proposal 3.1.4.5.1.1 Propose New Exit Point 3.1.4.5.1.2 Propose New Exit Level 3.1.4.5.2 Receive Response 3.1.4.5.3.1 Identify Any Resulting Entry/Transit/Exit Problems (ref)

3.1.4.5.4 Co-ordination Agreement Reached 3.1.4.5.4.1 Update FPS 3.1.4.5.5 Co-ordination Agreement Not Reached 3.1.4.5.5.1 Warn Unsolved of Entry/Transit/Exit Problems (ref)

PC PC(+)

Solutions restricted to a change in :- XFL XPT

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)

FPS Verbal, Telephone, Written

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

3.1.4.6 Request a Entry/Exit Radar Handover

3.1.4.6.1 Make Radar Handover Proposal 3.1.4.6.1.1 Request New Exit/Entry Heading 3.1.4.6.1.2 Request New Exit/Entry Level 3.1.4.6.1.3 Request New Exit/Entry Speed 3.1.4.6.2 Receive Response 3.1.4.6.2.1 Agree on Handover Conditions 3.1.4.6.2.1.1 Update FPS 3.1.4.6.2.2 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

3.1.4.7 Forward New Exit ETO

PC PC(+) None

The next sector is provided with a change in exit ETO to subsequently revise their FPSs

None Verbally , Telephone

Having been asked by the EC, the PC verbally informs the next sector of a ETO revision

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.1.5 Transfer Aircraft

3.1.5.1 Determine if Aircraft Can Be Transferred 3.1.5.1.1 Final Conflict Check - Conflict Management (ref) 3.1.5.1.2 Check Exit Conditions Will Be Reached - Assess Achievement of Exit Conditions (ref) 3.1.5.2 Instruct Aircraft to Change Frequency 3.1.5.3 Verify Readback 3.1.5.4 Update FPS

EC Pilot None

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

3.2.1.1 Identify Suspected Conflicts

EC PC None 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.

3.2.1.2 Search Aircrafts Plans for Conflicts

3.2.1.2.1 Get Aircraft's Position, Level and Time at Waypoints 3.2.1.2.2 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.2.1.2.3 Extrapolate Aircraft Positions Between Waypoints 3.2.1.2.4 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.

3.2.1.3 Search Radar for Conflicts

3.2.1.3.1 Linearly Extrapolate Aircraft Positions 3.2.1.3.2 Search for Interactions

EC None Identification of a radar conflict

Memory, RPVD (speed vectors, range and bearing)

None

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

3.2.1.4 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

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.

3.2.1.5 Postpone Conflict Solution

3.2.1.5.1 Consider Workload EC None

Knowledge of a suspected conflict and the required to monitor its evolution in the future.

None None

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

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.2.1.6.1 Find Conflict Solutions

3.2.1.6.1.1 Understand Aircraft Capability 3.2.1.6.1.1.1 Request Information (Aircraft Capability) from Aircraft [Plan and Execute Now] 3.2.1.6.1.2 Plan a Vectoring Solution 3.2.1.6.1.3 Plan Routing Solution 3.2.1.6.1.4 Plan Speed Solution 3.2.1.6.1.5 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

3.2.1.6.6 Verify Solutions

3.2.1.6.6.1 Linearly Extrapolate Conflict Solution 3.2.1.6.6.2 Linearly Extrapolate Other Aircraft

Positions 3.2.1.6.6.3 Get Aircraft's What-if Position, Level and Time at Waypoints 3.2.1.6.6.4 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.2.1.6.6.5 Search for Interactions

EC None One or more verified conflict solutions

Memory, FPS, RPVD (speed

vectors, range and bearing)

None

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

3.2.1.6.7 Choose Best Solution


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

?? None

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.

3.2.1.7 Update Aircraft's Plan with Conflict Solution Actions

EC PC None

Aircraft's plan incorporating newly added conflict solution actions, usually to be implemented fairly immediately. Triggering of Exit Conditions Assessment task.

None None

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

3.2.2.1 Get Current Aircraft State

3.2.2.1.1 Get Aircraft Location 3.2.2.1.2 Get Aircraft Level 3.2.2.1.3 Get Aircraft Speed

EC PC None Knowledge of the latest aircraft state (location, level & speed)

RPVD None Understand the real-time status information of the Aircraft. This usually consists of Location, Level & Speed. The PC may perform this task

3.2.2.2 Recall Aircraft Plan

3.2.2.2.1 Get Aircraft's Routing, RFL and Destination 3.2.2.2.2 Get Aircraft's Current Clearance

EC PC None

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

3.2.2.3 Check Conformance to Aircraft's Plan

3.2.2.3.1 Check Conformance to Flight Plan 3.2.2.3.2 Check Conformance to Instructions

EC PC None

Identification of a non-conformance, 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

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

3.2.2.5 Request Information (Non Conformance Rational) from Aircraft [Plan and Execute Now]

EC

See Request

Information from

Aircraft task


Knowledge of the pilot rationale behind a detected non-conformance



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.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.2.2.6 Correct Non-Conformance

3.2.2.6.1 Plan Reissuing the Instruction Being Non-Conformed With 3.2.2.6.2 Plan reissuing Appropriate Routing Instructions

EC None

A conformance corrections action(s) to be implemented when appropriate, usually fairly immediately.

FPS, E-FP, Memory

None

This task deals with the correction of non-conflictual non-conformances. 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 non-conflictual 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.

3.2.2.7 Update Aircraft's Plan With Non-Conformance Correction

EC None

Aircraft's plan incorporating newly added conformance correction actions, usually to be implemented fairly immediately.

None None The result of the conformance correction process is an update to the aircraft plan, to be implemented when appropriate (which is not necessarily instantaneously).

3.2.3.1 Identify Quality of Service Improvement

3.2.3.1.1 Consider a More Expeditious Sector Routing 3.2.3.1.2 Consider a More Efficient Vertical Profile 3.2.3.1.3 Consider a More Efficient Speed Profile 3.2.3.1.4 Consider a More Expeditious Exit Point 3.2.3.1.5 Consider a More Efficient Exit Level 3.2.3.1.6 Consider Issuing Turbulence Warning 3.2.3.1.7 Consider Issuing Context Traffic Information

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

One or more QoS improvements

RPVD, FPS, 'QoS improvements library'

None Look for QoS improvements from aircraft position, through transit to the exit.

3.2.3.2 Verify Quality of Service Improvement

3.2.3.2.1 Linearly Extrapolate What-if Aircraft Position 3.2.3.2.2 Linearly Extrapolate Other Aircraft Positions 3.2.3.2.3 Get Aircraft's What-if Position, Level and Time at Waypoints 3.2.3.2.4 Get Other Aircrafts' Positions, Levels and Times at Shared Waypoints 3.2.3.2.5 Search for Interactions

EC None One or more QoS verified improvements

Memory, FPS, RPVD (speed vectors, range and bearing)

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

3.2.3.3 Choose Best Quality of Service Solution

3.2.3.3.1 Consider Safety Assurance 3.2.3.3.2 Consider ATC Constraints 3.2.3.3.3 Consider Quality of Service Level 3.2.3.3.4 Consider Level of Workload

EC

Solutions consider:- Safety assurance provided ATC constraints Quality of service level provided Level of workload required

One QoS improvement. ?? None

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.

3.2.3.4 Plan Asking for an Aircraft Report

EC None A planned reporting to later trigger a QoS improvement

RPVD, FPS, 'QoS improvements library'

None

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.

3.2.3.5 Update Aircraft's

Plan with Quality of Service Improvements

EC None Aircraft's plan

incorporating QoS improvement actions.

None None

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

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.2.4.1 Assess Achievement of Exit Point and Level

3.2.4.1.1 Recall Exit Conditions 3.2.4.1.2 Identify if Conflict Solutions Prohibit Achieving Exit Conditions 3.2.4.1.2.1 Search Aircraft's Plan for Conflict Solutions 3.2.4.1.3 Identify if Aircraft Vertical Performance Prohibits Achieving Exit Level 3.2.4.1.3.1 Linearly Extrapolate Aircraft Vertical Position 3.2.4.1.4 Plan New Exit Conditions 3.2.4.1.4.1 Recall Exit Conditions From The Conflict Solution 3.2.4.1.4.2 Choose a New Exit Level 3.2.4.1.4.2.1 Plan New Level 3.2.4.1.4.2.1.1 Linearly Extrapolate What-if Aircraft Position 3.2.4.1.4.2.2 Verify New Level 3.2.4.1.4.2.2.1 Linearly Extrapolate What-if Aircraft Position 3.2.4.1.4.2.2.2 Linearly Extrapolate Other Aircraft Positions 3.2.4.1.4.2.2.3 Search for Interactions 3.2.4.1.4.2.3 Choose Best Level 3.2.4.1.4.2.3.1 Consider Safety Assurance 3.2.4.1.4.2.3.2 Consider Quality of Service Level 3.2.4.1.5 Choose Type of Co-ordination 3.2.4.1.5.1 Plan a Regular Exit Co-ordination 3.2.4.1.5.2 Plan a Exit Radar Handover

EC PC None

Possible revised (via co-ordination or radar handover) exit conditions due to a conflict solution or performance limitation.

Memory, FPS, RPVD (speed vectors, range and bearing)

None

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 co-ordination or radar handover requests are assessed and planned.

3.2.4.2 Assess Achievement of Exit ETO

3.2.4.2.1 Recall Original Exit ETO 3.2.4.2.2 Determine New Exit ETO 3.2.4.2.2.1 Request Information (Estimates) from Aircraft [Plan and Execute Now] 3.2.4.2.3 Plan to Forward a New ETO

EC Pilot PC

None Possible plan to send an ETO revision to the downstream sector

RPVD, FPS See Request Information from Aircraft task


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.

3.2.5 Workload Monitoring

3.2.5.1 Consider Current Workload Level 3.2.5.2 Consider Future Workload Level 3.2.5.2.1 Plan Co-ordinations to Minimise Future Workload 3.2.5.3 Inform Supervisor

EC, PC

SUP None

Knowledge of current and future workload as a result of incoming traffic and plans made upon it.

None Verbal

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

3.3.1 React to Unsolved Entry Problems

3.3.1.1 Detect Entering Aircraft With Problem - Detect Aircraft (ref) 3.3.1.2 Confirm and Solve Entry Conflict -

Conflict Management (ref) 3.3.1.3 Identify if Entry Conflict Solution Requires a Change in Entry Conditions 3.3.1.3.1 Search Aircraft's Plan for Conflict Solution 3.3.1.4 Plan and Perform an Entry Radar Handover

EC None

Planned solutions to entry problem. Possible entry radar

handover planning

See Assume Aircraft sub-tasks 3&5

See Assume Aircraft sub-tasks 3&5

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.

3.3.2 Respond to Safety Net Alerts

3.3.2.1 Refine Conflict Detail 3.3.2.1.1 Linearly Extrapolate Aircraft Positions 3.3.2.1.2 Search for Interactions 3.3.2.2 Solve Conflict (ref) 3.3.2.3 Update Aircraft's Plan with Conflict Solution Actions

EC See Solve Conflict sub-tasks

See Solve Conflict sub-tasks

See Update Aircraft's Plan with Conflict Solution

Actions

RPVD, TDB See Solve

Conflict sub-tasks

None STCA and MSAW alert the controller to an immanent conflict. The controller responds by solving the conflicts as if it detected by him/her

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


3.3.3 Respond to Received Co-ordinations

3.3.3.1 Receive Co-ordination Proposal 3.3.3.2 Assess Proposal 3.3.3.2.1 Verify Proposal is Problem Free - Verify Solution (ref) 3.3.3.3 Make Counter-Proposal 3.3.3.4 Co-ordination Agreement Reached 3.3.3.4.1 Update FPS 3.3.3.5 Co-ordination Agreement Not Reached

PC PC(-) PC(+)

Solutions restricted to a change in :- PEL NPT XFL XPT

An agreed and recorded change in entry or exit (changed plan) conditions No agreement

FPS See Solve Conflict sub-tasks

Verbal, Telephone, Written

Co-ordinations from adjacent sectors interrupt the PC and require immediate response. If an exit condition is changed the EC is informed.

3.3.4 Respond to Received Radar Handover Proposals

3.3.4.1 Receive Radar Handover Proposal 3.3.4.2 Assess Proposal 3.3.4.2.1 Verify Proposal is Conflict Free - Verify Solutions (ref) 3.3.4.3 Respond to Proposal 3.3.4.3.1 Agree on Handover Conditions 3.3.4.3.1.1 Update Aircraft's Plan with Handover Conditions 3.3.4.3.1.1.1 Update FPS 3.3.4.3.2 Disagree on Handover Conditions

EC EC(-) EC(+)

Solutions restricted to a change in :- XFL, XPT NFL, NPT or a :- specific heading specific speed

An agreed and recorded set of radar handover conditions (update to the plan). Exit conditions are usually implemented ASAP. No agreement


Verbal, Telephone, Written

Radar Handover requests from adjacent sectors interrupt the EC and require immediate response. If an exit condition is changed the EC updates the plan and will issue intructions soon.

3.3.5 Process Aircraft Requests

3.3.5.1 Receive Request 3.3.5.2 Assess Request 3.3.5.2.1 Verify Request is Conflict Free - Verify Solutions (ref) 3.3.5.2.2 Check If Request Requires Co-ordination 3.3.5.2.2.1 Plan Exit Co-ordination 3.3.5.3 Make Alternative Proposal 3.3.5.4 Grant Request 3.3.5.4.1 Update Aircrafts Plan with Requested Conditions 3.3.5.5 Acknowledge Request 3.3.5.5.1 Consider Request in Future Quality of Service Tasks 3.3.5.6 Deny Request

EC Pilot

Requests are:- Direct Level TOD

Request (or alternate) granted and subsequent implementation planning Request denied Request acknowledged for future QoS tasks Requirement for downstream co-ordination


R/T See Solve Conflict sub-tasks

Aircraft requests EC and require immediate response

3.3.6 Respond to Aircraft Reports

3.3.6.1 Receive Report 3.3.6.2 Respond to Requested Reports 3.3.6.2.1 Integrate Report into Aircraft's Planning 3.3.6.3 Respond to Unrequested Reports 3.3.6.3.1 Turbulence Report 3.3.6.3.1.1 Process Accompanying Request (ref) 3.3.6.3.1.2 Add Information to Quality of Service Planning 3.3.6.3.2 ETO Report 3.3.6.3.2.1 Assess Achievement of Exit Conditions (ref) 3.3.6.3.3 TCAS Report 3.3.6.3.3.1 Observe TCAS Manoeuvre

EC

Report types:- Requested reports Report passing etc Unrequested reports Turbulence ETO change TCAS

An expected report acts to trigger a QoS action already planned. Unexpected reports act as information input other continuous tasks

Pilot, RPVD R/T The task of responding to expected and unexpected reports from the aircraft

3.3.7 Respond to ETO Revision

3.3.7.1 Receive Revision 3.3.7.2 Update FPS

PC PC(-) None ETOs are updated FPS Verbal, Telephone, Written

The response when an ETO change is received from the upstream sector. Note the aircraft is usually some distance from PC's sector when a revision is received

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


6 TOWER TASK ANALYSIS

6.1 TOWER TASK ANALYSIS APPROACH

6.1.1 Purpose of the Tower Task Analysis

The task analysis for the Tower Control Working position was undertaken as part of the Integrated Tower Working Position project and Episode 3 (Human Factors Assessment). The main objectives of the task analysis was to identify the main task processes carried out in the Control Tower in order to use it as a base line and cross-check that all critical tasks can still be successfully completed and how controllers’ tasks change from existing systems to the future systems.

6.1.2 Method of the Tower Task Analysis

In order to carry out the task analysis, the initial step involved visiting four Control Towers (Stockholm Arlanda, London Gatwick, Rome Fiumucino and Naples Capodichino) in order to collect information about existing positions, controller roles, tasks, equipment and applications. Controllers were observed, and the working methods used by the controllers in the various towers and the systems and interfaces that they were currently using were recorded. This initial study was used to generate a comprehensive analysis and breakdown of the different generic tasks carried out in each control tower position (Clearance Delivery, Ground and Runway) in terms of a hierarchy of goals, sub-goals, operations and plans, using a hierarchical task analysis. The scope of the information included categories such as task duration, the cognitive processes involved, performance requirements, criticality, equipment used etc. The initial hierarchical task analysis was expanded and input into a Task Analysis Software tool (Task Architect, Version 1.3.6) in the format of a Tabular Task Analysis (TTA) breaking down the major tasks into subtasks. An in-house Operational Expert was interviewed in order to validate the relevant information needed to construct the TTA and a comprehensive analysis of each subtask was done (i.e. Cognitive/Sensory Attributes involved, Performance Requirements, Controls and Displays used, Criticality, Output/Feedback, Concurrent Task etc). The HTA was then further validated by members of the ITWP ANSP Stakeholder group through a group brainstorming session and walkthrough analyses.

The Task Analysis was also used to create a Human Factors Usability Questionnaire that has been applied during a Human-In-the-Loop simulation in order to investigate whether or not the controllers found the ITWP prototype usable. In addition, it has been used during brainstorming sessions and walk-through analysis by the ANSP controllers to try and determine how the tasks change from existing systems to the ITWP prototype. A further review exercise was undertaken in order to validate the task analysis, where follow-up visits were made to the ATC towers at Arlanda Airport in Stockholm and Orly airport in Paris and observational methods were used to cross-check the task analysis against the current tasks being carried out in all controller positions in a real-life situation. Although the Task Analysis is quite generic, a number of small differences were locally identified – especially in relation to the organisation of runways which can have a direct impact on the way tasks are distributed between arrivals/departures and ground controllers. As mentioned above, the task analysis will be used as a baseline to cross-check that all control tower tasks can be successfully completed. In relation to the ITWP project, it will be used to measure how controllers’ tasks change from existing system to the new platform. For future reference, it is also expected to be a useful documentation of current tower working methods.

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


6.2 TOWER TABULAR TASK ANALYSIS RESULTS

Task Sub Tasks Type of Task Purpose

1.Clearance Delivery Controller

1.1 Receives and Checks FPS

1.1.1 Retrieves FPS from printer 1.1.2 Checks and Update Strip Data 1.1.2.1 Checks Wake Vortex 1.1.2.1.1 If Wake Vortex is Heavy and it is not already marked, mark 'H' on FPS 1.1.2.2 Check Call Sign 1.1.2.3 Check Stand Number 1.1.2.3.1 Record on Strip 1.1.2.4 Check Aircraft Type 1.1.2.4.1 Record on Strip 1.1.2.5 Place Strip in Slot in Strip Bay

Building up of mental picture, monitoring, managing landing/departing aircraft, planning traffic management.

To record/update flight information. To prepare for receiving startup.

1.2 Receives Start-up call 10-15 mins before EOBT

1.2.1 Activate the FPL/RPL (Flight plan) by inputting the FDPS with the start-up request from the flight crew

Inputting of information received Updating the flight plan

1.3 Carry out Checks

1.3.1 Double-check Stand Number and A/C Type on SAFIR Display

Building up mental picture, monitoring, managing landing/departing ac, handing paper strips

Safety

1.4 Check against FPS and update if necessary

1.4.1 Check Delay times, CTOT times on the E2K 1.4.1.1 Update Flight plan

Building up of mental picture, managing landing/departing aircraft, handle paper strips

To record/update flight information

1.5 Issue ATC and Start-up Clearances

1.5.1 Issue ATC Clearance for Departures 1.5.1.1 Specify SID

Managing landing/departing ac, managing requests. Act on

To initiate flight on schedule

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



1.5.1.1.1 Local Path 1.5.1.1.2 Level to climb to 1.5.1.2 Specify Squawk 1.5.1.2.1 Transponder or SSR Code 1.5.1.2.2 Double-check Weather Information on AWOS 1.5.1.3 Specify Airway (Route to Destination) 1.5.1.4 Specify Ground Controller frequency to contact for pushback 1.5.1.5 Confirm Departure Runway 1.5.2 Issue Start-up Clearance 1.5.2.1 Instruct Pilot to start-up engines 1.5.2.2 Instruct Pilot to contact Ground Controller

aircraft

1.6 Transmit ATC and Start-up Clearances Simultaneously

1.6.1 Transmit ATC Clearance 1.6.2 Transmit Start-up Clearance

Communication, managing landing/departing aircraft

Give clearance

1.7 Decide whether to send DEP MSG to AFTN

1.7.1 If a message is sent, mark with a Red Pen

Decision-making To highlight that a message has been sent

1.8 Pass on FPS to GND

1.8.1 Pass strip to Flight Data Assistant 1.8.1.1 FDA Relays Strip to GND

Coordination Make sure that the controller receives the appropriate FPS

2 Ground Controller

2.1 Departures

2.1.1 Receive and Organise Strips

2.1.1.1 Receive Strip 2.1.1.2 Check Strip

Building up of mental picture, planning traffic management,

To record update flight information, to initiate

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



2.1.1.2.1 Time 2.1.1.2.2 Callsign 2.1.1.2.3 Aircraft Type 2.1.1.2.4 Destination 2.1.1.3 Place FPS on Panel in the Pushback and Departure Sequence

handling paper strips, handling new priorities

flight on schedule, to establish pushback and departure sequence

2.1.2 Approve Pushback

2.1.2.1 Receive Call requesting pushback clearance 2.1.2.1.1 Transfer FPS From Pending Bay to Active Bay 2.1.2.2 Initiate Pushback 2.1.2.2.1 Contact Pilot to see if they are ready for pushback 2.1.2.2.1.1 If Pilot is ready for pushback 2.1.2.2.1.1.1 Check Departure time and compare to time 2.1.2.2.1.1.2 If time is OK, do a visual check 2.1.2.2.1.1.2.1 If No Obstacles perceived, Approve Pushback 2.1.2.2.1.1.2.1.1 Annotate Strip (Time, Stand Number, etc. Depending on Local Procedures). 2.1.2.2.1.1.2.2 If Obstacles perceived on visual check Disapprove Pushback 2.1.2.2.1.1.2.2.1 Contact appropriate person to take action. 2.1.2.2.1.2 If Pilot is not ready for Pushback, Replace strip in Pending Bay and Continue to Monitor Situation

Building up of mental picture, monitoring, communicating/coordinating with other controllers. Handle paper strips. To transfer control of aircraft

To initiate flight on schedule To transfer aircraft to holding point To transfer control of aircraft

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



2.1.3 Issue Taxi Clearance

2.1.3.1 Answer Request 2.1.3.2 Check Departure Information 2.1.3.2.1 Check Slot Times 2.1.3.3 Select Standardized route 2.1.3.3.1 Issue Clearance to Taxi 2.1.3.3.1.1 Give Directions to take 2.1.3.3.1.2 Give Taxiways to follow 2.1.3.3.1.3 Specify Holding point 2.1.3.3.1.4 Record Taxi Route if necessary

Monitoring, communicating/.co-ordination with other controllers

To transfer aircraft to holding point

2.1.4 Transfer Aircraft

2.1.4.1 Decide when to transfer aircraft 2.1.4.1.1 Decide when it's on appropriate time or aircraft are at an appropriate location 2.1.4.2 Distribute strip to RWY CNR at or just before holding point (by hand or electronically) 2.1.4.2.1 Instruct Aircraft to contact RWY Controller

Building up of mental picture, monitoring, communicating/coordinating with other controllers

To transfer control of aircraft

2.2 Arrivals Building up of mental picture, monitoring, communicating/coordinating with other controllers

To bring aircraft to stand

2.2.1 Receive Arrival A/C when vacating Runway

2.2.1.1 Receive Aircraft Call 2.2.1.2 Receive Strip from RWY or FDA 2.2.1.3 Place strip on strip bay 2.2.1.3.1 Update Strip

Communicating, monitoring, co-ordination with other controllers

Updating strip when aircraft is vacating runway

2.2.2 Give taxi clearance to 2.2.2.1 Write on Strip (if that is the procedure) Organisation, monitoring To give taxi clearance

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



arriving traffic exiting to stand (via standardized route).

2.2.2.1.1 Remove strip from panel 2.2.2.1.1.1 Place in a piile in front of panel.

2.3 Towed Aircraft Building up of mental picture, monitoring, communicating/coordinating with other controllers

For safety purposes to ensure separation between towed a/c and other traffic

2.3.1 Receives a call from the Apron Controllor, identifying a towed aircraft

2.3.1.1 Place an electronic label on the ASMGCS Display 2.3.1.2 Keep a trace on aide-memoire 2.3.1.3 Monitor towed aircraft at regular intervals

Communication, monitoring

2.3.2 Record from (Stand)

2.3.3 Record to (Stand)

2.3.4 Record via (taxiway)

3 Arrivals Controller (RWY)

3.1 Manage Arrivals

3.1.1 Receive Strips 3.1.1.1 Arrange Strips in Sequence on Strip-Board according to Inbound Flight order 3.1.2 Monitor Approach Radar 3.1.2.1 Check Seperation on Final Approach (about 4 miles out) 3.1.2.1.1 Coordinate with Approach Controller as required 3.1.2.1.2 Rearrange Strips if needed

Building up of mental picture, monitoring, managing landing aircraft, planning traffic management. Coordination with other controllers and aircraft, decision-making.

Ensure that aircraft lands safely For safety to check approach sequence

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



3.1.3 Landing Clearance 3.1.3.1 Check Runway & if landing clearance can be given 3.1.3.1.1 Check wind information 3.1.3.1.1.1 Relate wind information to pilot 3.1.3.1.2 If runway is free and wind is OK, give landing clearance 3.1.3.1.3 If landing clearance cannot be given, Instruct Aircraft to Go-Around 3.1.3.1.3.1 Coordinate with Air Departures to ensure separation is maintained 3.1.3.1.3.2 Issue tactical instructions to ensure that separation is maintained 3.1.4 Record Required Arrivals Information on Strips 3.1.4.1 Mark A/c Landing time on strip

3.2 Issue Runway EXIT instructions

3.2.1 Coordinate with Ground Controller as required Coordination

3.2.2 Check Aircraft has cleared Runway

3.2.2.1 Transfer A/C to GND 3.2.2.1.1 Distribute Paper Strip to GND

Monitoring, communication Making sure that the aircraft has left the runway before transferring it to GND controller

3.3 Carry out Vehicle Related Tasks

3.3.1 Give Clearance for vehicles to enter runway

3.3.1.1 Check Traffic Situation Monitoring Ensuring that it is safe for vehicles can enter the runway

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



4 Departures Controller (RWY) 4.1 Manage Departures Building up of mental picture,

monitoring, managing departing aircraft, planning traffic management

4.1.1 Receives Strips from GND Controller, either by hand or electronically

4.1.1.1 Lines up Strips in Departure Sequence

Coordination, organisation Receive relevant flight strips regarding departing aircraft

4.1.2 Estimates Final Departure Sequence

4.1.2.1 Take into account all constraints 4.1.2.1.1 Refer to Departure times on strips 4.1.2.1.2 Refer to the airport and taxiway layout 4.1.2.1.3 Take into account Aircraft Types 4.1.2.1.3.1 Speed 4.1.2.1.3.2 Size 4.1.2.1.3.3 Wake Vortex Classification 4.1.2.1.4 Take into account Time Constraints 4.1.2.1.5 Take into account Aircraft Sequence 4.1.2.1.6 Take into account the availability of Taxiways and Exits

Managing Departing aircraft, managing Requests/ Act on a/c Building up of mental picture, monitoring, communicating/co-ordinating with others.

To arrange the most efficient departure sequence To get the aircraft into a position for take off To get aircraft airborne To transfer control of aircraft to the next controller responsible

4.1.3 Give Line-up Clearance when next in

4.1.3.1 Ensure Appropriate Seperations 4.1.3.2 Check Position of other relevent traffic using ASMGCS and

Communication, monitoring, decision-making

To make sure that there is appropriate separation between aircraft lining up

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



Taxiway Sequence

External View to taxi

4.1.4 Deliver Take-off Clearance

4.1.4.1 Check Runway is free using ASMGCS and External View 4.1.4.2 Check and give Wind Information 4.1.4.3 Record any relevent information on FPS, i.e. Airborne Time

Building up of mental picture, monitoring, communicating.

Provide relevant information

4.1.5 Carry out Departure Sequence

4.1.5.1 Check Alltitude if Required 4.1.5.2 Check Squawk and Call-sign Correlation

Cross-checking information Ensuring that all relevant information is correct for clearance to runway

4.1.6 Transfer A/C to Departure Controller

4.1.6.1 Communicate with Departure Controller if required 4.1.6.2 Update FPS to indicate transfer of Aircraft 4.1.6.3 Remove FPS from Bay 4.1.6.3.1 Place FPS in a pile to the side 4.1.7.1 Give Clearance for vehicles to enter runway

Communication, Transferral of aircraft to next controller responsible

4.1.7 Carry out Vehicle Related Tasks

4.1.7.1.1 Check Traffic Situation

Monitoring

5 Flight Data Assistant (The Runner)

5.1 Collects Flight Strips

5.1.1 Sorts Arrivals from Departures

Handling paper strips Separate the arrival from the departure strips

5.2 Answers Phone Calls on 5.2.1 Takes Charge of Answering phone calls when the supervisor is Communication Answering phone when

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30



Supervision Position

unavailable

supervisor is occupied

5.3 Checks Data

Checks the Data on the SAFIR Display Monitoring Making sure data is correct

5.4 Ensures Telephone Liasons with Vehicles

5.4.1 Coordinates with supervisor when necessary 5.4.1.1 Reports the position of vehicles on magnetic car map placed on LEFT side of position 5.4.1.1.1 **Monitors and Checks Magnetic car map against external view 5.4.1.1.2 Updates Magnetic Car map

Communication and Coordination

5.5 Ensures communication with cars in case of snow or heavy traffic

Communication

5.6 Distributes Outbound Flight Strips

5.6.1 Relays Strips from Collection point to Clearance Delivery 5.6.2 Recollects strips from Clearance Delivery 5.6.3 Distributes Strip to GND Position when transferred

Coordination, distribution and collection of flight strips

Ensure that controller receives the outbound flight strips

5.7 Distributes Inbound Flight Strips

5.7.1 Writes the Parking Stand on strips when available 5.7.2 Distributes the arrival strip to the arrival TWR RWY Controller.

Distribution Ensure that the controller receives the inbound flight strips

Episode 3



Date: 30-06-2007

N°: 1.01

Status: Approved

of 30


END OF DOCUMENT

today’s operations task analysis - eurocontrol · 2019-02-18 · episode 3 d2.4.4-05 today’s...

Documents