predicting performance and workload - eurocontrol

EUROPEAN ORGANISATIONFOR THE SAFETY OF AIR NAVIGATION

(852&21752/�(;3(5,0(17$/�&(175(

9$/,'$7,21�2)�$�0(7+2'2/2*<�)25�35(',&7,1*3(5)250$1&(�$1'�:25./2$'

((&�1RWH�1R��

Project HUM-7-E3

Issued: June 1999

The information contained in this document is the property of the EUROCONTROL Agency and no part should bereproduced in any form without the Agency’s permission.

The views expressed herein do not necessarily reflect the official views or policy of the Agency.

EUROCONTROL

5(3257�'2&80(17$7,21�3$*(

5HIHUHQFH�EEC Note No. 7/99

6HFXULW\�&ODVVLILFDWLRQ�Unclassified

2ULJLQDWRU�EEC - ATM

($ir 7raffic 0anagement R&D)

2ULJLQDWRU��&RUSRUDWH�$XWKRU��1DPH�/RFDWLRQ�EUROCONTROL Experimental CentreB.P.15F - 91222 Brétigny-sur-Orge CEDEXFRANCETelephone : +33 (0)1 69 88 75 00

6SRQVRU�ATM Human Resources

6SRQVRU��&RQWUDFW�$XWKRULW\��1DPH�/RFDWLRQ�EUROCONTROL AgencyRue de la Fusée, 96B -1130 BRUXELLESTelephone : +32 2 729 9011

7,7/(�

9$/,'$7,21�2)�$�0(7+2'2/2*<�)25�35(',&7,1*

3(5)250$1&(�$1'�:25./2$'

$XWKRULiz Cullen

Human Engineering Limited

'DWH

6/993DJHV

vii + 33)LJXUHV

67DEOHV

14$SSHQGLFHV

55HIHUHQFHV

8

($7&+,3�7DVN6SHFLILFDWLRQ

-

3URMHFW

HUM-7-E3

7DVN�1R��6SRQVRU

�

3HULRG

1998 to 1999

'LVWULEXWLRQ�6WDWHPHQW�(a) Controlled by: Project Manager HTI(b) Special Limitations: None(c) Copy to NTIS: YES / NO

'HVFULSWRUV��NH\ZRUGV��

Air Traffic Control – IMPACT Project - Task Analysis - Task Model - Methodology - Performance PredictiveModel - Workload Predictive Model

$EVWUDFW�

This report describes a study, under the auspices of an EEC project (which seeks to determine the IMPACTof process change or new technology on the controllers way of working and its consequence on training - theIMPACT Project). This study was conducted by Human Engineering (UK) Ltd (HEL).

The subject of the study is a work programme to validate, within the ATM environment, a methodology forpredicting human performance and workload. This methodology was developed by HEL and successfullyapplied within other industrial fields. The aim of this study is to test the applicability of these principles withinthe ATM field.

This document has been collated by mechanical means. Should there be missing pages, please report to:

EUROCONTROL Experimental CentrePublications Office

B.P. 1591222 - BRETIGNY-SUR-ORGE CEDEX

France

9DOLGDWLRQ�RI�D�0HWKRGRORJ\�IRU�3UHGLFWLQJ�3HUIRUPDQFH��:RUNORDG

Y

(852&21752/

��

*/266$5<�2)�7(506«««««««««««««««««««««««««««««YL

(;(&87,9(�6800$5<««««««««««««««««««««««««««««�YLL

�� ,1752'8&7,21 ��

1.1. Background .................................................................................................................1

1.2. Objectives ....................................................................................................................3

1.3. Overview Of Work Programme ...................................................................................3

�� 7$6.�02'(/�'(9(/230(17 ��

2.1. Overview......................................................................................................................4

2.2. Data .............................................................................................................................4

2.3. Cognitive Task Analysis ..............................................................................................4

�� 3(5)250$1&(��:25./2$'�35(',&7,21 ��

3.1. Overview Of Analysis Procedure...............................................................................12

3.2. Scenario Model Development....................................................................................12

3.3. Performance Prediction..............................................................................................13

3.4. Workload Prediction ..................................................................................................17

3.5. Predicted Performance...............................................................................................19

3.6. Predicted Workload ...................................................................................................20

3.7. Potential Sources Of Error .........................................................................................21

�� 5(68/76�2)�9$/,'$7,21��

4.1. Predicted Task Durations...........................................................................................23

4.2. Predicted Sequence Of Activity.................................................................................26

4.3. Predicted Controller Workload ..................................................................................28

�� &21&/86,216��)857+(5�:25.��

5.1. Conclusions ...............................................................................................................31

5.2. Recommendations .....................................................................................................32

�� 5()(5(1&(6 ��

$33(1',;�$��+LHUDUFKLFDO�7DVN�$QDO\VLV�>LQFOXGLQJ�$QQH[�$��7DVN�0RGHO@

$33(1',;�%��([DPSOH�2I�6HOHFWLRQ�5XOHV

$33(1',;�&��3UHGLFWHG�7DVN�6HTXHQFLQJ��:RUNORDG

$33(1',;�'��3HUIRUPDQFH�0RGHOOLQJ�8VLQJ�$WODV

$33(1',;�(��$QDO\VLV�3ORWV


YL

(852&21752/

��

&RJQLWLYH�7DVN�$QDO\VLV Analysis process used within the methodology to develop thetask model.

+HXULVWLFV Rules of thumb used in the validation work programme due tothe limitations in the data available for testing purposes.

0HWKRGRORJ\ The methodology for predicting performance and workloadwhich is being validated in this work programme.

4H�0RGHO The sub-component of the methodology which is used forpredicting workload.

6FHQDULR�0RGHO Model of the ATM scenario which represents traffic and radarinformation as an event timeline.

6HOHFWLRQ�5XOHV Rules used implicitly by the controller in performing tasksequences which are expressed explicitly in the task model.

7DVN�0RGHO Model of controller activity which includes detailedbehavioural and task information.


([HFXWLYH�6XPPDU\ YLL

(852&21752/

��

This document reports on a work programme to validate, within air traffic management (ATM),a methodology for predicting human performance and workload. This work programme wasconducted by Human Engineering on behalf of Eurocontrol.

The predictive methodology is being developed as part of a wider programme of cognitivemodelling research. This is an attempt to integrate the current theories incorporated withinHuman Engineering’s ATLAS© tool and the WINCREW© tool developed by the US ArmyResearch Laboratory (Reference 1).

The aim of the methodology is to allow performance and workload to be predicted early withinthe design process to support the integration of human factors into the development of advancedsystems. Application of the methodology for prediction purposes involves 3 steps. Initially atask model is constructed through a process of cognitive task analysis (CTA). A scenario modelis then produced as an event timeline. Finally, the task and scenario models are used together topredict performance and workload.

As a logical development of existing theories, and as part of a wider research programme withincognitive modelling, it is expected that this methodology will produce a more theoreticallycoherent means of predicting performance and workload than is currently available. However,to ensure a broad ranging applicability and utility, it is necessary to undertake validation studiesin as wide a range of applications as possible. Consequently, in addition to a current validationstudy within a military application, this work programme was devised to conduct a parallelvalidation within air traffic management.

The work programme conducted to validate the methodology comprised two major elements.Initially the methodology was applied to an air traffic management application to produce a taskmodel (Stage 1) and to predict controller performance and workload (Stage 2). The accuracy ofthe predictions was then assessed to highlight areas of the methodology requiring furtherdevelopment (Stage 3). The assessment focused on the predicted timings, performancesequences and workload.

It is concluded that the methodology does have the potential to be a useful tool within cognitivemodelling. In some areas, the prediction of performance and workload was successful, andwhere this was not the case, the reasons for the errors were anticipated and related todeficiencies within the task model and to the level of control that could be achieved in this workprogramme over the scenario used in Stages 2 and 3. Together these acted to obstruct thevalidation process as they produced errors in the predictions that are not likely to be attributableto problems with the methodology itself. Consequently, it is suggested that these are addressedthrough further development of the task model and by obtaining, for use throughout theanalysis, more detailed scenario information than was available from the video. This wouldallow a more effective validation of the methodology to be undertaken.

________________________©Human Engineering Limited 1996©Micro Analysis & Design Inc. 1997


([HFXWLYH�6XPPDU\

(852&21752/

,QWHQWLRQDOO\�OHIW�EODQN


,QWURGXFWLRQ �

(852&21752/

�� ,1752'8&7,21

�� %DFNJURXQG

Within air traffic management (ATM), the ability to predict controller performance andworkload is of great importance to the continued improvement of air safety. Inparticular, it allows the investigation of proposed new traffic management systems, interms of their effect on controller behaviour.

Human Engineering is currently developing a methodology to predict performance andworkload. This is an attempt to integrate the current theories of cognitive modellingincorporated within Human Engineering’s ATLAS tool and the WINCREW tooldeveloped by the US Army Research Laboratory (Reference 1). The approach uponwhich the model is based is shown in Figure 1.

SUBJECTIVEWORKLOAD

Requirement forcoping strategy

TASK GOALSIncluding Task Characteristics

(e.g. Priority, dependencies)

TASKSEQUENCE

PERFORMANCEQUALITY

Performance vs goalSTRATEGY

COGNITIVEDEMANDS

(Vs. Limitations)

Figure 1

In summary, the JRDOV of a task are translated by an individual into a VWUDWHJ\ forachieving these goals. In line with the strategy, a WDVN�VHTXHQFH is performed. Thisresults in a set of FRJQLWLYH�GHPDQGV�which are determined by the behaviours involvedin the tasks being performed. The effect of these demands is twofold. On the one hand,the individual perceives VXEMHFWLYH�ZRUNORDG as a function of these demands in the

Human Engineering Limited 1996 Micro Analysis & Design Inc. 1997


� ,QWURGXFWLRQ

(852&21752/

context of cognitive limitations. Where this is felt to be excessive, the requirement for acoping strategy initiates an alternative task sequence and a new set of cognitivedemands. This loop is reiterated until the subjective workload becomes acceptable. Theacceptability of the cognitive demands also affects SHUIRUPDQFH�TXDOLW\�such thatunacceptable demands (either too high or too low) result in poor performance quality.Finally, the quality of the performance when compared to the goal can result in theindividual modifying the WDVN�JRDOV and/or the VWUDWHJ\ being used to achieve the goals.

ATLAS incorporates the Qe model of workload (see Reference 2) . This is derived fromtheories of information processing and attempts to move away from traditionalapproaches to workload prediction which tend to express workload as a singlemeaningless statistic. The approach within WINCREW is concerned with the effect ofstrategy on performance and workload.

The methodology under development integrates these two strands of work to produce amodel of operator strategy that can be used to predict performance (in terms of thesequence of activities) and workload (in terms of demand and behavioural conflict).

The aim of the methodology is to allow performance and workload to be predicted earlywithin the design process to support the integration of human factors into thedevelopment of advanced systems. Application of the methodology for predictionpurposes involves 3 steps. These are outlined below and described more fully in themain body of the report.

6WHS��'HYHORSPHQW�2I�$�7DVN�0RGHO

This is achieved through a process of cognitive task analysis (CTA) and incorporates thetheories within ATLAS and WINCREW. The task model comprises the followinginformation derived in consultation with a subject matter expert:• A listing of tasks in a hierarchical format decomposed to the level of individual

behaviours.• Task priorities and interruptibility.• Task durations (derived using ATLAS’s performance modelling algorithms).• Selection rules which specify what to do next according to events within a scenario.

6WHS��3URGXFWLRQ�2I�$�6FHQDULR�0RGHO

This involves the development of an event timeline of the simulated scenario for usewith the selection rules to predict task sequences.

6WHS��3HUIRUPDQFH�$QG�:RUNORDG�3UHGLFWLRQ

Initially, performance is predicted using the task model in conjunction with the scenariomodel. Subsequently, workload is predicted by applying the Qe model to the predictedtask sequences.

As a logical development of existing theories, which forms part of a wider researchprogramme within cognitive modelling, it is expected that this methodology willproduce a more theoretically coherent means of predicting performance and workloadthan is currently available.


,QWURGXFWLRQ �

(852&21752/

A current work programme being conducted by Human Engineering involves thevalidation of the methodology within a military application. However, to ensure a broadranging applicability and utility, it is necessary to undertake validation studies in aswide a range of applications as possible. Consequently, the methodology is also beingvalidated within air traffic management, on behalf of the Controller Work PositionGroup within Eurocontrol. This work programme, conducted by Human Engineering, isdescribed in this document.

�� 2EMHFWLYHV

This study forms part of a wider programme of cognitive modelling research for thedevelopment of tools to support performance and workload prediction. Within thisresearch programme, the methodology which has been developed is to be validatedacross a range of applications.

The study reported in this document is a validation exercise within air trafficmanagement. Specifically, the objective of the work was to assess the capability of themethodology in predicting performance and workload within air traffic management.This involved using the methodology to predict controller performance and workload,and then assessing the accuracy of the predictions to identify the strengths andweaknesses of the methodology, and the requirements for further development. Ingeneral this will identify what can be learned about the methodology from its applicationto ATM.

The approach taken within the work programme is described below.

�� 2YHUYLHZ�2I�:RUN�3URJUDPPH

The work programme conducted to validate the methodology comprised two majorelements. Initially the methodology was applied to an air traffic managementapplication to produce a task model (Stage 1, see Section 0) and to predict controllerperformance and workload (Stage 2, see Section 3). The accuracy of the predictions wasthen assessed to highlight areas of the methodology requiring further development(Stage 3, see Section 4).

This document is divided into 5 sections. The following section (Section 0) describesthe work conducted in Stage 1 to develop the task model. Section 3 reports on theperformance and workload prediction performed in Stage 2 of the work programme.The results of the validation are presented in Section 4. Finally, Section 5 includes theconclusions of the work programme and requirements for further work.

In addition to this document, the work completed in Stages 1 and 2 has been reported indocuments HEL/EC/97152/RT1 and HEL/EC/97152/RT2 respectively.


� 7DVN�0RGHO�'HYHORSPHQW

(852&21752/

�� 7$6.�02'(/�'(9(/230(17

�� 2YHUYLHZ

The development of the task model of controller operations involved a process ofcognitive task analysis (CTA) using the methodology. At the basis of the task modelwas a hierarchical task analysis (HTA) which is a top down breakdown of thecontroller’s activities. This was then elaborated using CTA to represent the moredetailed task information. The WINCREW approach to cognitive modelling wasrepresented in the task model as a set of selection rules governing task strategy and itsimplications for performance and workload.

Task data for the analysis were obtained from videoed ATM operations in an advancedsimulator. The analysis of these data is described in the following sections. The taskmodel is provided in Annex A.

�� 'DWD

The task data analysed during the task model development was derived from videorecordings of the simulator trials conducted for the PD1+ research programme. Thetapes were obtained from the Air Traffic Management Development Centre (ATMDC)in Bournemouth.

From the videos provided, the tape selected for analysis was that of the TacticalController on Sector 10 using the baseline technology level (Org 0). The time period forthe run was approximately 55 minutes, the first 15 minutes of which were relativelyinactive. Consequently, the duration of the run containing useful data wasapproximately 40 minutes. The data were required to build the task model, and also totest the methodology. Consequently, the time period between 15 and 35 minutes wasused in Stage 1 to build the task model. The period between 35 and 45 minutes wasthen used in Stages 2 and 3 to predict performance and workload and to analyse theaccuracy of the predictions.

�� &RJQLWLYH�7DVN�$QDO\VLV

The CTA involved several stages of analysis. An overview of these is provided inSection 2.3.1. Detailed descriptions are provided in Sections 2.3.2 to 2.3.8.

�� 2YHUYLHZ�2I�&7$

The CTA involved the application of the methodology to the task informationderived from the video. The analysis also captured controller strategy byincorporating the relevant concepts from the WINCREW tool.

The first step in the cognitive task analysis (CTA) was the breakdown of thecontroller’s activity into its constituent components. This was achieved usinghierarchical task analysis (HTA), as described in Section 2.3.2. The tasks werethen described in terms of their behaviours. Following this, the CTA involved


7DVN�0RGHO�'HYHORSPHQW �

(852&21752/

elaborating the task information further. A primary goal of this analysis was toassess the predictive utility of the methodology. It was essential, therefore, tocapture the knowledge used by the controller to perform the correct tasks inappropriate sequences. These knowledge elements are termed ‘selection rules’and are the rules used implicitly by the controller to execute task sequences.They are represented within the task model as explicit rules that can be used bythe methodology to predict task performance. As the project timescaleconstraints meant that the work focused on strategic prediction rather than taskdeclarative knowledge, the more basic knowledge elements within ATM (e.g.call sign labels) were not recorded in the task model.

The task model was recorded in a database, and is presented in Annex A. Theindividual elements of the analysis are described below.

�� +LHUDUFKLFDO�7DVN�$QDO\VLV

To complete the HTA, the video was carefully examined to produce a list of thefull range of tasks performed by the controller. These were then representedhierarchically, using the structure applied within ATLAS.• The top level of the ATLAS hierarchy is the µ0LVVLRQ¶ level. This is in effect

the overall goal of the activity, in this case the requirement to ensure the safepassage of the aircraft through the sector.

• At the next level of the hierarchy are the µ3KDVHV¶. These represent a seriesof activities which are performed to meet a sub-goal, for example ‘Deal withincoming aircraft’.

• The activities comprising a ‘Phase’ are represented at the µ)XQFWLRQ¶ level.• At the next level are µ7DVNV¶ which are single activities that are performed as

part of ‘Functions’.• Finally, at the bottom level of the hierarchy are the individual human

EHKDYLRXUV that are involved in task performance.

This structure is described and illustrated with an example in Table 1 andAppendix A. All tasks within the task model are numbered according to theconvention shown in Table 1.

/HYHO 1XPEHULQJ ([DPSOH

Mission - Ensure safe passage of aircraft through thesector

Phase 1, 2, 3.... Deal with incoming aircraftFunction 1.1, 1.2, 1.3..... Identify aircraft calling inTask 1.1.1, 1.1.2, 1.1.3.... Scan radar for correct TDBBehaviours Not numbered • Locate TDB

• Read TDB (call sign)• Compare TDB call sign with stated

call sign

7DEOH��([DPSOH�RI�+7$



(852&21752/

The HTA was verified with 3 subject matter experts (SMEs) and modified wherenecessary. A total of 85 tasks were identified. The final task breakdown isincluded in the task model in Annex A.

�� %HKDYLRXUDO�,QIRUPDWLRQ

Following the task breakdown, the CTA involved describing the behavioursusing the modified VACP classification system contained within ATLAS (seeReference 3). This assigns to each individual behaviour the appropriate term forthe Visual (V), Auditory (A), Cognitive (C) and Psychomotor (P) behaviourinvolved. The VACP descriptors are listed in Table 2.

9LVXDO $XGLWRU\ &RJQLWLYH 3V\FKRPRWRUDetect Detect Simple Reaction SpeakText Symbology Verify Feedback Recognise Reach/SwitchSearch Locate Choice Reaction ManipulateInspect/Check Interpret Speech Calculate Adjust/MoveCompare Identity Verify & Locate Decide ControlTrace Compare Recall/Prepare KeyingAlign Track Analyse Pattern Judge Write/Draw

7DEOH��9$&3�'HVFULSWRUV

�� ,QLWLDWLRQ

The next element of the CTA was the analysis of the initiating conditions of eachof the 85 tasks. This was necessary for the initiation of tasks in the prediction inStage 2. The analysis involved identifying the ‘trigger’ for each task, andcategorising the initiation as follows:

• )ROORZ�RQ� The task is triggered by the completion of another task. Thistypically applies to tasks within the same function.

• 5XOH�EDVHG� The task is triggered by the satisfaction of required conditionswithin the selection rules of a completed task. For example, Task 8.1.1 ofFunction 8.1 (Change heading to resolve conflict - Change heading RT) istriggered on the basis of the conflict type and traffic conditions.

• ([WHUQDO� The task is triggered by an external event within the scenario.Only two tasks are externally initiated. These are Task 1.1.1 (Listen toaircraft calling in) which is triggered by an aircraft calling in, and Task 3.6.1(Gather info on conflicting aircraft) which is triggered by the initiation of theconflict alert. For these tasks, the relevant event was also recorded in thedatabase.

�� ,QWHUUXSWLELOLW\��3ULRULW\

As part of the CTA, the interruptibility and priority of each function wasanalysed. This information was essential to the development of the selectionrules (see Section 2.3.6). The categorisation process is described below.

)XQFWLRQ�3ULRULW\

The priority of each function was initially categorised as ‘Urgent’, ‘High’‘Medium’ or ‘Low’. This was determined from analysis of controller preferences



(852&21752/

during the videoed simulator trials. The categorisation was then verified with anSME, and it was agreed that there was no requirement to discriminate betweenfunctions of ‘Medium’ and ‘Low’ priority. Consequently, ‘Medium’ and ‘Low’priority functions were categorised as ‘Low’ priority. The final classification ofpriority, therefore, was:• Urgent• High• Low

)XQFWLRQ�,QWHUUXSWLELOLW\

The interruptibility of each function was discussed with an SME, andcategorised as follows:

1RQ�LQWHUUXSWLEOH ,QWHUUXSWLEOH

If:• Function priority is urgent, or• Function comprises a single RT

instruction concurrent with thetask ‘Edit TDB’.

If:• Conditions for non-

interruptibility are not satisfied(see adjacent column).

7DVN�,QWHUUXSWLELOLW\

In addition to function interruptibility, the CTA involved the analysis of theinterruptibility of the WDVNV. This is partly dependent on the interruptibility of thefunction to which a task belongs, such that tasks within non-interruptiblefunctions are also non-interruptible. Tasks within interruptible functions,however, can be either interruptible or non-interruptible, depending on theirnature. This factor was determined from observation of the video, such that thecontrollers propensity to complete a task before moving onto another onedictated its categorisation of interruptibility.

Task interruptibility was categorised in the task model as ‘Yes’ or ‘No’ andrecorded in the database. This information was used in the prediction in Stage 2to specify whether or not a task required completion prior to initiation of the nexttask. For example, if an aircraft calls in on the RT, the controller willimmediately deal with that aircraft if the task currently being performed isinterruptible (e.g. 11.1.1 - Housekeeping - Move TDBs). Conversely, in cases ofnon-interruptible tasks (e.g. 1.2.1 - Accept a/c on frequency - Accept a/c (RT)),the current task will be completed prior to dealing with the new aircraft.

�� 6HOHFWLRQ�5XOHV

In order to predict task sequencing, it is essential to capture the rules used by thecontroller during next task selection. Whilst these rules will be implicit withinthe controller’s knowledge base, they are represented explicitly within the taskmodel for use in the methodology, and are termed ‘selection rules’.

On completion of one task, the selection rules specify the appropriate next task,given the scenario conditions. An example is the rule specifying the requirement



(852&21752/

for housekeeping. The rule implicit within the controller’s knowledge base isthat housekeeping tasks should be performed if the radar is judged to becluttered. Within the methodology (i.e. the selection rules in the task model),this is represented as:• ,I�&OXWWHU� �+LJK��7DVN��0RYH�7'%V�

• ,I�&OXWWHU� �/RZ��7DVN�[�[�[��where Task x.x.x is the next chronological taskwithin the current function.

The selection rules are also illustrated in an example in Appendix B.

The selection rules were derived in consultation with an SME. Necessarymodifications were made as required. The rules ranged from simple rules forselecting the next task within a function, to the complex rules associated withconflict resolution. The scenario variables used in the rules to specify theappropriate next task are listed in Table 3, together with the source of theinformation and its use.

6FHQDULR�9DULDEOH 6RXUFH�2I�,QIRUPDWLRQ 8VH�2I�,QIRUPDWLRQ

Times at which an aircraft callsin.

Input manually To initiate Task 1.1.1(Identify a/c calling in -Listen to a/c calling in).

Details of specific aircraft e.g.call sign, actual flight level(AFL), exit flight level (XFL),heading (hdg), release fromprevious sector (Yes/No),acceptance by next sector(Yes/No).

Input manually when anaircraft enters the sectorand updated automaticallyas changes are made (e.g.to flight levels).

To initiate tasks involved inchanging flight levels,putting aircraft on ownnavigation etc.

Times at which the conflictalert is initiated.

Input manually. To initiate Task 3.6.1(Assess conflict alert -Gather info on conflictinga/c).

Presence of a conflict(Yes/No).

Input manually. To determine therequirement to resolve aconflict (e.g. on the basis ofwhether or not the conflictalert is true or false), soinitiating the tasks involvedin formulating a plan forconflict resolution.

Details of conflict (e.g. conflicttype, status of aircraft i.e. levelor changing flight level).

Input manually. To initiate appropriateconflict resolutionstrategies.

Number of aircraft at eachflight level.

Input manually andupdated automatically aschanges are made.

Used in the assessment ofthe viability of potentialconflict resolutionstrategies and thus in theinitiation of appropriatetasks for conflictresolution.



(852&21752/

6FHQDULR�9DULDEOH 6RXUFH�2I�,QIRUPDWLRQ 8VH�2I�,QIRUPDWLRQ

Planner controller (PC)availability.

Input manually. To determine theinvolvement or non-involvement of the Plannerin formulating a plan forconflict resolution.

Degree of radar clutter. Input manually. To initiate housekeepingtasks.

Controller workload (WL). Calculated automaticallyusing Qe model.

To specify next taskswhere the choice isdependent upon workloadlevels.

Details of Function -x and Task-x.(These are the previousfunctions and tasks such thatFunction -1 is the functionbeing performed immediatelyprior to the current one,Function -2 is that which wasperformed prior to Function -1etc. The same applies to Task -x.)

Calculated automaticallywithin the methodology.

To specify the requirementto return to a previous taskin cases where a functionor task is interrupted.

Number of times Task x.x.x.has been performed in thecycle.

Calculated automaticallywithin the methodology.

To specify the requirementto begin a new function orto continue with theexisting one.

7DEOH��6FHQDULR�9DULDEOHV

In many cases, the source of the traffic information is specified as a manual inputwhich is obtained from observation of the video. This was necessary within thiswork programme due to the lack of an alternative source of the information. Forfuture analyses the event and traffic information could probably be obtaineddirectly from the simulation data, thus reducing the effort involved at this stageof using the methodology. However, analyses early in the design process, whensimulation data are not available, would still require manual derivation and inputof information during the development of the scenario model.

Also included in the selection rules are the rules for performing the twoexternally initiated tasks i.e.:• Task 1.1.1 (Identify a/c calling in - Listen to a/c calling in) which is initiated

when an aircraft calls in.• Task 3.6.1 (Assess conflict alert - Gather on conflicting a/c) which is

triggered when a conflict alert is initiated.

The external events that initiate the requirement to perform these two tasks canarise at any time within the scenario. When one of these events occurs, thecontroller can eithera) complete the function currently being performed, then begin Task 1.1.1

(Listen to a/c calling in) or 3.6.1 (Gather info on conflicting a/c), asappropriate, or


�� 7DVN�0RGHO�'HYHORSPHQW

(852&21752/

b) interrupt the function currently being performed, and immediately beginTask 1.1.1 (Listen to a/c calling in) or 3.6.1 (Gather info on conflicting a/c),as appropriate.

The rules specifying which of a) and b) above is the most appropriate actiondepends upon the interruptibility of the function, and its priority compared tothat of the externally initiated functions (i.e. Function 1.1 - Identify a/c calling inand Function 3.6 - Assess conflict alert). The categorisation of functions interms of priority and interruptibility is described in Section 2.3.5. The rules,based on these, for selection of a) or b) above are given below.

When conflict alert is initiated:• All QRQ�LQWHUUXSWLEOH functions will be completed prior to initiation of Task

3.6.1 (Assess conflict alert - Gather info on conflicting a/c).• All LQWHUUXSWLEOH functions will be interrupted to allow Task 3.6.1 (Assess

conflict alert - Gather info on conflicting a/c) to be triggered.

When an aircraft calls in:• 1RQ�LQWHUUXSWLEOH functions will be completed prior to initiation of Task

1.1.1 (Listen to a/c calling in). (This includes the function of µ8UJHQW¶priority).

• ,QWHUUXSWLEOH functions of µ+LJK¶ priority, will be completed prior toinitiation of Task 1.1.1 (Listen to a/c calling in).

• ,QWHUUXSWLEOH functions of µ/RZ¶ priority will be interrupted to allow Task1.1.1 (Listen to a/c calling in) to be triggered.

All the selection rules are written in the ‘If X then Y’ format. They are recordedin the ‘Selection Rules’ field in the task model database.

�� (IIHFW

The correct prediction of controller activity is heavily dependent upon theaccuracy of the scenario model. Consequently, it is essential that the relevantdetails of the scenario are regularly updated. The information within thescenario model that requires updating is included in the list in Table 3.

The updating of this information is achieved automatically by the use of the field‘effect’ in the task model. This field describes, for each task, any effect the taskhas on the scenario. For example, accepting an aircraft on frequency has theeffect of increasing the number of aircraft at its actual flight level by 1.Consequently, after the task of accepting an aircraft is completed, the scenariomodel will be updated automatically to reflect this. The updated information inthe scenario model will then be used, as required, in subsequent rule-basedselections of next tasks.

�� 'XUDWLRQV

In order to predict controller activity over time, it is necessary to know theduration of each task that is performed. The methodology is flexible enough to


7DVN�0RGHO�'HYHORSPHQW ��

(852&21752/

allow for two sources of this information. These are the observed durations andthe predicted durations, both of which were derived in this programme to allowan assessmen6t of this component of the methodology to be conducted.

The observed durations of tasks were derived from the analysis of the video. Tocapture the variability in these durations, where possible, a minimum of threeinstances of each task were recorded. However, since the variability in the taskdurations was determined by factors that cannot be predicted by the methodology(e.g. number of words in an RT transmission which is dependent upon controllerpreferences and the need for corrections within the transmission etc.), a fixedduration was specified. This is the mean of the durations observed in the video,and is recorded in the task model.

The predicted durations were calculated using the performance modellingalgorithms within ATLAS. This entailed calculating performance times for tasksbased on their component behaviours. Within the current work programme, thepredicted durations of tasks were computed in Stage 2. The derivation ofpredicted durations is described in Section 3.3.


�� 3HUIRUPDQFH��:RUNORDG�3UHGLFWLRQ

(852&21752/

�� 3(5)250$1&(��:25./2$'�35(',&7,21

Following development of the task model using CTA, the methodology was used to predictcontroller performance and workload for a selected scenario. This is described in Sections 3.1to 3.6. In addition, the potential sources of error within the methodology were also predicted.This was done to anticipate the causes of any inaccuracies in the prediction that might beidentified in Stage 3 of the work programme. The potential sources of error are listed inSection 3.7.

�� 2YHUYLHZ�2I�$QDO\VLV�3URFHGXUH

The prediction of controller performance and workload using the methodology involvedthree main analysis steps.

Initially a scenario model of the air traffic sample was constructed for the 15 minuteperiod of video selected in Stage 1. This involved inputting relevant scenario events(e.g. an aircraft calling in), and the information required for the selection rules withinthe task model.

The next analysis step was the performance prediction which addressed two keyelements. The task durations were predicted using the performance modellingcapability of the ATLAS tool. Subsequently, the task sequences were predicted usingthe task model.

The final analysis step was the workload prediction. This involved the application ofthe Qe model (Reference 2) to the task data to assess the cognitive loading on thecontroller throughout the time period.

These analysis steps are described below.

�� 6FHQDULR�0RGHO�'HYHORSPHQW

The first step in the prediction process was the development of an event timeline of thescenario on the video. This involved inputting the information required to predict thecontroller’s performance (i.e. task sequences) using the task model developed in Stage 1of this work programme. Specifically this information included the following detailsrequired for next task selection using the task model:

i) Times at which an aircraft called in.ii) Details of specific aircraft e.g. call sign, actual flight level (AFL), exit flight level

(XFL), whether on a heading (hdg), release from previous sector (Yes/No),acceptance by next sector (Yes/No). These details were input when an aircraftappeared on frequency were updated automatically during the time period aschanges resulted from the predicted controller activity (e.g. to flight levels).


3HUIRUPDQFH��:RUNORDG�3UHGLFWLRQ ��

(852&21752/

iii) Times at which the conflict alert was initiated. Also, whether or not the alert wastrue or false. In the absence of any other indicator, the latter information was basedupon the response of the controller to the alert.

iv) Presence of a conflict (Yes/No). Each conflict was input when it originally occurredand remained ‘live’ (i.e. un-resolved) until the controller was predicted to resolve it.This information was derived from the detailed observation of the video. The timeof occurrence of the conflict was input as the time at which the second aircraftinvolved in the conflict appeared on frequency. However, as it is likely that theconflict had existed prior to this point, the time of occurrence was rounded to thenearest 10 seconds.

v) Details of the conflicts (e.g. conflict type, status of aircraft i.e. level or changingflight level).

vi) Initial conditions e.g. number of aircraft at each flight level, number of aircraft onfrequency, number of aircraft on headings. These were input at the start of thetimeline within the scenario model. They were updated automatically as changeswere predicted.

vii) Number of TDBs approaching the edge of the sector (outbound) throughout thescenario. The quality of the video meant that it was not possible to determine thisaccurately. Consequently, this information was input as ‘0’ or ‘Greater than 0’,alternating as appropriate when the situation changed.

viii) Planner controller (PC) availability throughout the scenario. This is dependentupon the activities of the Planner which it was not possible to observe in this workprogramme. Consequently, it was assumed that the Planner was availablethroughout the time period.

ix) Degree of radar clutter. This was input as ‘High’ or ‘Low’ at 10 second intervals.Its main determinant was the extent to which TDBs for aircraft were obscured byothers.

For this work programme, the above information was derived from observation of thevideo. Whilst this was laborious and time consuming, future analyses using themethodology should be able to obtain the required information directly from the trafficsimulation programme. Consequently, the levels of effort involved in this part ofperformance and workload prediction could be reduced significantly.

�� 3HUIRUPDQFH�3UHGLFWLRQ

Following construction of the scenario model, the performance of the controller waspredicted using the task model developed in Stage 1 of the work programme. Therewere two key elements to this prediction, namely the prediction of task durations andtask sequences. Task durations were predicted prior to task sequences since durationhas an impact on sequence. For example, in the time available before an aircraft calls in(at time x), the number of tasks the controller can perform prior to dealing with theincoming aircraft depends on the durations of the tasks concerned.

A total of 10 minutes of activity were predicted, covering the time segment on the videobetween 35 minutes and 45 minutes. The results are presented in Section 3.5 and



(852&21752/

Appendix C. The derivation of task durations and sequences, together with the issuesraised during the work, are discussed below.

�� 7DVN�'XUDWLRQV

The task durations were predicted using ATLAS’s performance modellingalgorithms (see Appendix D). These can be used to derive fast, medium andslow values for task completion time. In this work programme, there was noindication of where the controller’s performance speed fell within the possiblerange of values. Consequently, the medium predicted durations were used.

�� 7DVN�6HTXHQFHV

Subsequently, the methodology was used to predict task sequences. Inparticular, this utilised the selection rules within the task model. The predictionbegan, at 35 minutes, with the first task of the monitoring phase. The following10 minutes were then predicted on a second to second basis using the selectionrules in combination with the information within the scenario model. This wasperformed manually which, though laborious, allowed an informal assessment ofthe accuracy of the selection rules throughout the analysis process. Futureanalyses using the methodology could be significantly more efficient if themethodology were to be automated within a computer programme.

�� 7DVN�0RGHO�0RGLILFDWLRQV

Throughout the manual prediction process deficiencies in the task model, thatwere not apparent during the model development in Stage 1, emerged as it wasapplied to the real ATM scenario. It was found that one rule was in need of asimple modification, whereas others required more extensive development andexpansion. In order to maximise the utility of the work programme, the simplemodification was implemented during the analysis. This is detailed below.

• With reference to Task 3.1.4 (Determine focus for monitoring - Determinerequired action), the time interval that is required to have passed betweeninstances of particular monitoring tasks is specified as 300 seconds. Thiswas felt to be excessive, particularly with regard to the identification ofaircraft requiring release (transfer). Consequently the interval was revised toa duration of 60 seconds.

In addition, it was necessary to develop some heuristics. These are outlinedbelow.

�� +HXULVWLFV

Heuristics were necessary given that the information available for the predictionwas limited, particularly with respect to aircraft details. For example, when thecontroller was predicted to be assessing an individual aircraft, it was not possibleto know which aircraft this was. The heuristics developed to get round theseproblems are described below.



(852&21752/

1. When the controller is predicted to release (transfer) an aircraft (Function2.1), it is necessary to know which aircraft this is so that the scenario modelcan be updated (in terms of the number of aircraft at the different flightlevels etc.). The scenario model does not indicate which aircraft are thefocus of the controller’s attention. Consequently, at Task 2.1.2 (Release a/c -Edit TDB), it was assumed that the aircraft being released was that whichhad been on frequency for the longest duration.

2. With reference to Task 3.1.4 (Determine focus for monitoring - Determine

required action), it is necessary to know the number of unreleased TDBs nearthe edge of the sector (outbound) at the start of the cycle as this dictates theappropriate focus for monitoring. As the information in the scenario modelonly specifies this value as ‘0’ or ‘Greater than 0’, it was assumed that thenumber of unreleased TDBs near the edge of the sector (outbound) at thestart of the cycle was 1. This means that the amount of time spentmonitoring aircraft for release was not excessive.

3. In determining whether or not an aircraft can be released (transferred)

(Function 3.2), it is necessary to know whether or not the aircraft is at its exitflight level (XFL) or on a heading. There is no information in the scenariomodel as to which aircraft this is. Consequently, at Task 3.2.2 (Determine ifany a/c require releasing - Determine required action), it was assumed thatthe aircraft in question was that which had been on frequency the longest.

4. In assessing an individual aircraft’s requirements (Function 3.3), it is

necessary to know at Task 3.3.2 (Assess individual a/c requirements -Determine required action) whether or not the aircraft in question is at itsXFL. Without any indication of which aircraft is the focus of the controller’sattention, it was necessary to adopt a heuristic. The chance that an aircraft isQRW at its XFL is defined by:

No.of a / c not at XFL

No.a / c on frequency at start of task cycle( ) − No.times task done in cycle( )

When the value of this expression was greater than or equal to 75%, theaircraft was assumed not to be at its XFL and the appropriate action wastaken.

5. In assessing an individual aircraft’s requirements (Function 3.3), it is

necessary to know at Task 3.3.4 (Assess individual a/c requirements -Determine required action) whether or not the aircraft in question is on aheading. Without any indication of which aircraft is the focus of thecontroller’s attention, it was necessary to adopt a heuristic. The chance thatan aircraft is on a heading is defined by:

No.of a / c on heading

No.a / c on frequency at start of task cycle( ) − No.times task done in cycle( )



(852&21752/

When the value of this expression was greater than or equal to 75%, theaircraft was assumed to be on a heading and the appropriate action wastaken.

6. In formulating a plan for conflict resolution (Phases 4, 5, 6 & 7), it is

necessary to know the details of the conflict in question. In this analysis, itwas not possible to know which conflict was being assessed by thecontroller. Consequently, the conflict in question at Tasks 4.2.2 (Formulateplan with Planner (Short term)- Select conflict resolution plan), 5.2.2(Formulate plan by self (Short term)- Select conflict resolution plan), 6.2.2(Formulate plan with Planner (Long term)- Select conflict resolution plan) &7.2.2 (Formulate plan by self (Long term)- Select conflict resolution plan)was assumed to be the unresolved conflict with the earliest origin. In caseswhere the phase was interrupted, on return to the tasks involved withformulating a plan, the activities were directed at the conflict previouslybeing assessed.

7. In formulating a plan for conflict resolution (Phases 4, 5, 6 & 7), the

selection of the appropriate resolution strategy (e.g. heading change versuslevel change) is based on several factors which are captured within theselection rules. One of the factors is whether or not a heading change isprohibited by traffic. The scenario model does not include the informationrequired to determine the viability of a heading change. Consequently, atTasks 4.2.2 (Formulate plan with Planner (Short term)- Select conflictresolution plan), 5.2.2 (Formulate plan by self (Short term)- Select conflictresolution plan), 6.2.2 (Formulate plan with Planner (Long term)- Selectconflict resolution plan) & 7.2.2 (Formulate plan by self (Long term)- Selectconflict resolution plan), it was assumed that a heading change wasprohibited for an aircraft if there were more than 2 other aircraft at the sameflight level.

8. When the controller is predicted to change a heading to resolve a conflict

(Function 8.1), and a heading change is viable for both aircraft (see number7 above) it is necessary to know which aircraft this instruction is given to sothat the scenario model can be updated. At Task 8.1.2 (Change heading toresolve conflict (1 a/c) - Edit TDB), therefore, the following assumptionswere made. If ERWK aircraft in the conflict were already on headings (e.g. forprevious conflict resolution), the controller was assumed to modify theheading of one aircraft. This has no effect on the scenario model as only thenumber of aircraft on headings not the details are recorded. Consequently,the aircraft in question does not need to be known in this case. If RQHaircraft in the conflict was already on a heading, the heading change wasassumed to be directed at the other aircraft. If QHLWKHU�aircraft in the conflictwas already on a heading, the heading change was assumed to be directed atthe aircraft at the flight level containing the least number of other aircraft (if



(852&21752/

levels are different) or that which had been on frequency the longest (if levelsare the same).

9. When the controller is predicted to return an aircraft to its own navigation

(Function 9.3), it is necessary to know which aircraft this is so that thescenario model can be updated (in terms of the number of aircraft at thedifferent flight levels etc.). At Task 9.3.2 (Put a/c own navigation - EditTDB), therefore, it was assumed that the aircraft being returned to its ownnavigation was that which was not involved in any conflict. If all the aircrafton headings were involved in conflicts, the aircraft returned to its ownnavigation was that which had been on a heading for the longest duration.

10. In assessing the implications of changing the flight level of an aircraft

(Function 10.1), it is necessary to know which aircraft is the focus of thecontroller’s attention. Consequently, at Task 10.1.4 (Assess implications ofchanging FL - Determine required action), the aircraft in question wasassumed to be that which had been on frequency the longest.

11. In assessing the implications of changing the flight level of an aircraft

(Function 10.1), it is necessary to know whether or not there are any possibleconflicts at the requested and interim flight levels. This information was notavailable in this analysis. Consequently, at Task 10.1.4 (Assess implicationsof changing FL - Determine required action), it was assumed that a possibleconflict existed if there were more than 2 aircraft at the requested or interimflight levels.

12. With reference to Task 10.2.4 (Assess implications of putting a/c on own

navigation - Determine required action), an aircraft can only be returned toits own navigation if the conflict in which it was/is involved has beenaverted. The scenario model does not include this information.Consequently, at Task 10.2.4 (Assess implications of putting a/c on ownnavigation - Determine required action), it was always assumed that theconflict under consideration had been averted.

�� :RUNORDG�3UHGLFWLRQ

The final step of applying the methodology was the prediction of controller workloadthroughout the 10 minute period. This prediction involved the application of the Qemodel (see Reference 2) at the point at which each task is performed.

The first stage in applying the Qe model to the task information developed in Stage 1was the description of the behaviours in the task model in terms of the Qe channelsrequired for the analysis. The behaviours and Qe channels assigned to them are listed inTable 4.



(852&21752/

%HKDYLRXU ,QSXW 3URFHVVLQJ 2XWSXWActivate phone - - ManualActivate RT - - ManualAssess degree of clutter - Spatial -Assess possibility of conflicts - Spatial/Symbolic -Check a/c accepted by next sector - Symbolic -Check a/c not on hdg - Symbolic -Check AFL = XFL - Symbolic -Compare AFL with XFL - Symbolic -Compare TDB call sign with stated callsign

- Symbolic -

Detect other a/c at requested & interimFLs

Visual Spatial/Symbolic -

Determine if a/c on a heading - Symbolic -Determine if conflict has been averted - Spatial/Symbolic -Determine if conflict is true - Spatial/Symbolic -Determine if there are any possibleconflicts

- Spatial/Symbolic -

Determine required action - Spatial -Determine type of conflict - Spatial -Listen to a/c Auditory Spatial/Symbolic -Listen to next sector Auditory Spatial/Symbolic -Listen to Planner Auditory Spatial/Symbolic -Locate TDB Visual Spatial/Symbolic -Look at PVD Visual Spatial -Move TDBs Visual Spatial ManualOpen tool (e.g. FFP) Visual - ManualRead outbound TDB near edge ofsector

Visual Symbolic -

Read TDB (call sign) Visual Symbolic -Read TDB (FL info) Visual Symbolic -Read TDB (Hdg info) Visual Symbolic -Read TDBs Visual Symbolic -Read TDBs for above a/c Visual Symbolic -Read TDBs for conflicting a/c Visual Symbolic -Read tool (e.g. FFP) Visual Symbolic -Review mental model - Spatial -Select ’assume’ from TDB Visual - ManualSelect ’release’ from TDB Visual - ManualSelect FL from TDB Visual - ManualSelect heading from TDB Visual - ManualSelect speed from TDB Visual - ManualTalk to a/c - Spatial/Symbolic VerbalTalk to next sector - Spatial/Symbolic VerbalTalk to Planner - Spatial/Symbolic Verbal

7DEOH��%HKDYLRXUV�DQG�4H�FKDQQHOV

Once the behaviours had been described in terms of the Qe channels, the Qe modelanalysis steps were applied (see Reference 2).



(852&21752/

Under normal circumstances, the Qe analysis determines workload at time t on the basisof the behaviours involved in the tasks being performed at that instant. In this workprogramme, however, many of the functions end with the task ‘Determine requiredaction’ which, unlike most other tasks, comprises only a single behaviour. This meansthat the workload at these points is always ‘Acceptable’. The tasks to which this appliesinclude those where the selection rules are based in part upon workload levels (i.e. ifworkload = high, do x; if workload = low, do y). Consequently, the next task selected isalways that specified for cases when workload is low. Since this was thought to beunrealistic, the application of the Qe calculation was modified to include thebehavioural information for the previous task, as well as that for the current task. Thiswas, however, only applied to the following tasks:

• ‘Determine required action’• ‘Determine type of conflict’

The result was a more realistic and useful prediction of workload.

The results are described in Section 3.6.

�� 3UHGLFWHG�3HUIRUPDQFH

The predicted task sequence for the 10 minute period is provided in Appendix C, andsummarised as a list of the sequences of phases in Table 5 below.

6WDUW 3KDVH 6WDUW 3KDVH 6WDUW 3KDVH

35:00 3 Monitoring 38:50 3 Monitoring 42:25 4 Formulate plan withPlanner (ST)

35:02 11 Housekeeping 38:51 1 Deal with incoming a/c 42:27 3 Monitoring

35:04 3 Monitoring 39:00 10 Assess implications ofchanging a/c parameter

42:30 4 Formulate plan withPlanner (ST)

35:06 1 Deal with incoming a/c 39:06 3 Monitoring 42:42 8 Implement CR plan

35:16 10 Assess implications ofchanging a/c parameter


42:49 3 Monitoring

35:18 11 Housekeeping 39:22 8 Implement CR plan 42:58 2 Deal with outgoing a/c


39:36 3 Monitoring 43:07 3 Monitoring

35:24 3 Monitoring 40:16 1 Deal with incoming a/c 43:32 10 Assess implications ofchanging a/c parameter


40:26 3 Monitoring 43:37 9 Issue routine instructions

35:40 8 Implement CR plan 40:39 2 Deal with outgoing a/c 43:44 3 Monitoring

35:47 3 Monitoring 40:48 3 Monitoring 43:50 10 Assess implications ofchanging a/c parameter

35:49 11 Housekeeping 40:50 11 Housekeeping 43:56 9 Issue routine instructions

35:51 3 Monitoring 40:52 3 Monitoring 44:03 3 Monitoring

36:27 1 Deal with incoming a/c 41:06 6 Formulate plan withPlanner (LT)


36:37 3 Monitoring 41:08 11 Housekeeping 44:10 9 Issue routine instructions


41:10 6 Formulate plan withPlanner (LT)

44:17 3 Monitoring



(852&21752/

6WDUW 3KDVH 6WDUW 3KDVH 6WDUW 3KDVH

36:53 8 Implement CR plan 41:17 1 Deal with incoming a/c 44:19 10 Assess implications ofchanging a/c parameter

37:00 3 Monitoring 41:27 10 Assess implications ofchanging a/c parameter

44:25 3 Monitoring

37:15 6 Formulate plan withPlanner (LT)

41:33 9 Issue routine instructions 44:27 10 Assess implications ofchanging a/c parameter

37:49 8 Implement CR plan 41:40 3 Monitoring 44:32 9 Issue routine instructions

38:03 3 Monitoring 41:44 4 Formulate plan withPlanner (ST)

44:39 3 Monitoring

38:12 2 Deal with outgoing a/c 41:56 8 Implement CR plan 44:47 2 Deal with outgoing a/c

38:21 3 Monitoring 42:03 3 Monitoring 44:56 3 Monitoring


42:11 1 Deal with incoming a/c 44:58 11 Housekeeping

38:43 9 Issue routine instructions 42:21 3 Monitoring

7DEOH��3UHGLFWHG�3KDVH�6HTXHQFLQJ

�� 3UHGLFWHG�:RUNORDG

The predicted workload levels for the 10 minute period are given along with thepredicted task sequence in Appendix C. A summary is provided in Table 6 below. Thissummary details the time of occurrence of the predicted high (unacceptable) and low(acceptable) workload levels.

7LPH :RUNORDG

35:02 Low

35:06 Low

35:18 Low

35:23 High

35:39 High

35:49 Low

36:27 Low

36:52 High

37:48 High

38:11 High

38:51 Low

39:05 High

39:21 High

40:16 Low

40:38 High

40:50 Low

41:08 Low

41:17 Low

41:32 High

41:55 High

42:11 Low

42:41 High

42:57 High



(852&21752/

7LPH :RUNORDG

43:55 High

44:24 High

44:46 High

44:58 Low

7DEOH��2FFXUUHQFHV�2I�+LJK��/RZ�/HYHOV�2I�:RUNORDG

�� 3RWHQWLDO�6RXUFHV�2I�(UURU

The potential sources of error within the methodology which were identified during theprediction of controller activity and workload are listed in Table 7.

They are classified as follows:• HTA-related (i.e. related to the adequacy / completeness of the task listing in the

task model)• CTA-related (i.e. related to the detailed task information in the task model)• Scenario-related (i.e. related to limitations within the scenario model)

3RWHQWLDO�6RXUFH�2I�(UURU�+7$�UHODWHG�

/LNHO\�(IIHFW�2Q3UHGLFWLRQ

� The task breakdown (i.e. HTA) does not capture the task offine tuning an aircraft’s heading to keep the aircraft within anairway.

Task of fine tuning anaircraft’s heading tokeep the aircraft withinan airway not predictedin sequence of activity.

� The HTA does not reflect the fact that, following aninstruction, the controller monitors the progress of the trafficand may subsequently modify the instruction if the progress isunacceptable. For example, alternative strategies for conflictresolution may be adopted by the controller if the originalstrategy is believed to be ineffective.

Modification ofinstructions (e.g. forconflict resolution)occurs but is notpredicted.

� Observation of real task performance suggested that oldconflicts, involving aircraft whose details are known to thecontroller, are solved more quickly than new conflicts becausethe relevant details are known to the controller. A potentialsource of error in the prediction is the fact that the HTA doesnot differentiate between conflict resolution tasks (i.e.formulating a plan) directed at old conflicts and those directedat conflicts which are new.

Some observed conflictresolution tasks arecompleted morequickly than predicted.

3RWHQWLDO�6RXUFH�2I�(UURU�&7$�UHODWHG�


� The majority of the selection rules trigger a single task.Consequently, the task sequences predicted using the taskmodel contain very few tasks that are performed in parallel.Observation of real task performance suggests that paralleltask performance is more common than is predicted by the rulebase, so introducing a potential source of error in theprediction of both task sequences and workload.

Simultaneous taskperformance occurs butis not predicted. Thismay produce anunderestimation ofworkload.



(852&21752/

3RWHQWLDO�6RXUFH�2I�(UURU�&7$�UHODWHG�


� The task model does not capture the sharing of tasks betweenthe Tactical and Planner controllers. Observation of real taskperformance showed that the Planner would, in certaincircumstances, support the Tactical in a range of tasks (e.g.assuming aircraft, resolving conflicts, liaising with the nextsector).

Tactical controllerpredicted to performtasks which in realsituation are performedby Planner.

� The task model includes a selection rule which specifies thatthe phases concerned with formulating a plan for conflictresolution will be interrupted if an aircraft calls in onfrequency. A potential source of error is that, contrary to thisrule, the phase is unlikely to be interrupted if the conflict inquestion is urgent (e.g. one triggering a conflict alert alarm).In addition, once interrupted, the controller is not directedback to the planning activity by the selection rules, thusintroducing the possibility that the conflict would remainunsolved.

More conflictresolution activityoccurs and isinterrupted more in thereal situation than ispredicted.

� The selection rules for conflict resolution appear to be oversimplistic. In particular, the controller appears to take moreinto account than the status of the aircraft and the feasibility ofa heading change.

Conflict resolutionstrategies used aredifferent to thosepredicted.

� The task model can in some cases predict a repetitive loop ofactivity. For example, it is specified that once the controllerhas begun checking the radar for aircraft that may requirerelease (Function 3.2), the phase will, if uninterrupted by anaircraft call or conflict alert, be repeated until all the outboundTDBs near the edge of the sector have been checked. Thismeans that potential conflicts (NOT triggering conflict alert)arising during the time spent performing Function 3.2 may,unrealistically, be ignored.

Prediction includesloop of activity that isof longer duration thanoccurs in reality.

3RWHQWLDO�6RXUFH�2I�(UURU�6FHQDULR�UHODWHG�


� The scenario/ traffic sample used in the simulation is viewedby the controller as unrealistic. This may induce the controllerto perform unrealistic tasks which are not captured in theHTA.

Unrealistic tasksarising from perceivedlack of reality inscenario occur but arenot predicted.

�� The heuristics applied in the prediction were, necessarily, oversimplistic. These heuristics are very likely to be a source oferror in the prediction.

Non specific errors inprediction of tasks towhich heuristics areapplied.

7DEOH��3RWHQWLDO�6RXUFHV�2I�(UURU


5HVXOWV�RI�9DOLGDWLRQ ��

(852&21752/

�� 5(68/76�2)�9$/,'$7,21

The analysis conducted in Stage 3 comprised the following 3 three main stages:• Analysis of the accuracy of the predicted task GXUDWLRQV.• Analysis of the accuracy of predicted VHTXHQFH of activity.• Analysis of the accuracy of the predicted controller ZRUNORDG.

These are described below.

�� 3UHGLFWHG�7DVN�'XUDWLRQV

To assess the accuracy of the methodology in predicting task durations, the observeddurations (derived in Stage 1) were compared with the predicted durations (derived inStage 2). These are listed in Table 8. A successful prediction was taken to be a task forwhich the relative distance between the observed and predicted durations does notexceed +/- 20%.

7DVN

1R�

7DVN�1DPH

� � �RYHUW�WDVN�

3UHGLFWHG

'XUDWLRQ

�VHF�

2EVHUYHG

'XUDWLRQ

�VHF�

$EVROXWH

GLVWDQFH

�VHF�

5HODWLYH

GLVWDQFH

��1.1.1 *Listen to a/c calling in 3.0 2.9 0.1 +3.451.1.2 *Scan radar for correct TDB 2.0 1.4 0.6 +42.851.1.3 Determine required action 1.0 0.5 0.5 +100.001.2.1 *Accept a/c (RT) 2.0 1.8 0.2 +11.101.2.2 *Edit TDB 1.0 1.0 0.0 0.001.3.1 Examine a/c FL 1.0 1.6 0.6 -37.501.3.2 Determine required action 1.0 0.5 0.5 +100.002.1.1 *Release a/c (RT) (transfer) 9.0 8.4 0.6 +7.152.1.2 *Edit TDB 1.0 1.3 0.3 -23.053.1.1 Assess degree of clutter 1.0 0.5 0.5 +100.003.1.2 Determine requirement to

housekeep1.0 0.5 0.5 +100.00

3.1.3 Review air picture 2.0 0.5 1.5 +300.003.1.4 Determine required action 1.0 0.5 0.5 +100.003.2.1 Gather info on outbound a/c 3.0 3.8 0.8 -21.053.2.2 Determine required action 1.0 0.5 0.5 +100.003.3.1 Gather info on FL 1.0 3.9 2.9 -74.353.3.2 Determine required action 1.0 0.5 0.5 +100.003.3.3 Gather info on Hdg 1.0 3.9 2.9 -74.353.3.4 Determine required action 1.0 0.5 0.5 +100.003.4.1 Gather info on traffic 3.0 9.7 6.7 -69.053.4.2 Determine required action 1.0 0.5 0.5 +100.003.5.1 Gather info on traffic 10.0 29.5 19.5 -66.103.5.2 Determine required action 1.0 0.5 0.5 +100.003.6.1 Gather info on conflicting a/c 2.0 2.6 0.6 -23.103.6.2 Determine required action 1.0 0.5 0.5 +100.004.1.1 Gather info on traffic from TDBs 3.0 4.6 1.6 -34.754.1.2 *Discuss conflict with Planner 3.0 4.6 1.6 -34.754.1.3 Determine type of conflict 1.0 1.0 0.0 0.004.2.1 Assess feasibility of options 4.0 4.6 0.6 -13.054.2.2 Determine required action 1.0 0.5 0.5 +100.005.1.1 Gather info on traffic from TDBs 3.0 6.0 3.0 -50.005.1.2 Determine type of conflict 1.0 1.0 0.0 0.00


�� 5HVXOWV�RI�9DOLGDWLRQ

(852&21752/

7DVN

1R�

7DVN�1DPH


3UHGLFWHG

'XUDWLRQ

�VHF�

2EVHUYHG

'XUDWLRQ

�VHF�

$EVROXWH

GLVWDQFH

�VHF�

5HODWLYH

GLVWDQFH

��5.2.1 Assess feasibility of options 4.0 5.9 1.9 -32.205.2.2 Determine required action 1.0 0.5 0.5 +100.006.1.1 Assess degree of clutter 1.0 0.5 0.5 +100.006.1.2 Determine requirement to

housekeep1.0 0.5 0.5 +100.00

6.1.3 Gather info on traffic from TDBs 10.0 6.0 4.0 +66.656.1.4 *Gather info on traffic from tools 5.0 6.1 1.1 -18.016.1.5 *Discuss options with Planner 8.0 6.0 2.0 +33.356.1.6 Determine type of conflict 1.0 1.0 0.0 0.006.2.1 Assess feasibility of options 7.0 6.1 0.9 +14.756.2.2 Determine required action 1.0 0.5 0.5 +100.007.1.1 Assess degree of clutter 1.0 0.5 0.5 +100.007.1.2 Determine requirement to

housekeep1.0 0.5 0.5 +100.00

7.1.3 Gather info on traffic from TDBs 10.0 5.5 4.5 +81.807.1.4 *Gather info on traffic from tools 5.0 5.5 0.5 -7.457.1.5 Determine type of conflict 1.0 1.0 0.0 0.007.2.1 Assess feasibility of options 7.0 5.6 1.4 +25.007.2.2 Determine required action 1.0 0.5 0.5 +100.008.1.1 *Change Hdg (RT) 7.0 7.9 0.9 -11.408.1.2 *Edit TDB 1.0 1.6 0.6 -37.508.2.1 *Change FL (RT) 7.0 6.9 0.1 +1.458.2.2 *Edit TDB 1.0 3.3 2.3 -69.708.3.1 *Request speed info (a/c 1) (RT) 7.0 6.6 0.4 +6.058.3.2 *Request speed info (a/c 2) (RT) 7.0 6.6 0.4 +6.058.3.3 *Restrict/change speed (a/c 2)

(RT)7.0 6.7 0.3 +4.45

8.3.4 *Edit TDB (a/c 2) 1.0 1.0 0.0 0.008.3.5 *Restrict/change speed (a/c 1)

(RT)7.0 6.7 0.3 +4.45

8.3.6 *Edit TDB (a/c 1) 1.0 1.0 0.0 0.008.4.1 *Change Hdg (a/c 1) (RT) 7.0 7.9 0.9 -11.408.4.2 *Edit TDB (a/c 1) 1.0 1.6 0.6 -37.508.4.3 *Change Hdg (a/c 2) (RT) 7.0 7.9 0.9 -11.408.4.4 *Edit TDB (a/c 2) 1.0 1.6 0.6 -37.508.5.1 *Stop climb / descent (RT) 7.0 6.9 0.1 +1.458.5.2 *Edit TDB 1.0 3.3 2.3 -69.708.6.1 *Stop climb / descent (a/c 1) (RT) 7.0 6.9 0.1 +1.458.6.2 *Edit TDB (a/c 1) 1.0 3.3 2.3 -69.708.6.3 *Stop climb / descent (a/c 2) (RT) 7.0 6.9 0.1 +1.458.6.4 *Edit TDB (a/c 2) 1.0 3.3 2.3 -69.709.1.1 *Change FL (RT) 7.0 6.9 0.1 +1.459.1.2 *Edit TDB 1.0 3.3 2.3 -69.709.2.1 *Change FL (RT) 7.0 6.9 0.1 +1.459.2.2 *Edit TDB 1.0 3.3 2.3 -69.709.3.1 *Put a/c on own navig (RT) 7.0 7.3 0.3 -4.109.3.2 *Edit TDB 1.0 1.0 0.0 0.00

10.1.1 Assess degree of clutter 1.0 0.5 0.5 +100.0010.1.2 Determine requirement to

housekeep1.0 0.5 0.5 +100.00

10.1.3 Gather info on traffic 3.0 0.5 2.5 +500.0010.1.4 Determine required action 1.0 0.5 0.5 +100.0010.2.1 Assess degree of clutter 1.0 0.5 0.5 +100.00



(852&21752/

7DVN

1R�

7DVN�1DPH


3UHGLFWHG

'XUDWLRQ

�VHF�

2EVHUYHG

'XUDWLRQ

�VHF�

$EVROXWH

GLVWDQFH

�VHF�

5HODWLYH

GLVWDQFH

��10.2.2 Determine requirement to

housekeep1.0 0.5 0.5 +100.00

10.2.3 Gather info on traffic 2.0 0.5 1.5 +300.0010.2.4 Determine required action 1.0 0.5 0.5 +100.0011.1.1 *Move TDBs 2.0 3.4 1.4 -41.1512.1.1 *Talk with adjacent sector 13.0 9.0 4.0 +44.45

0HDQ ��

7DEOH��&RPSDULVRQ�2I�7DVN�'XUDWLRQV

From Table 8 it can be seen that of the 85 tasks contained within the task model, 29 taskdurations (approximately 34%) were predicted to within a margin of +/- 20%. Inaddition, the distribution of errors in the prediction is shown below, in Table 9.

&OXVWHU 1XPEHU�RI�WDVNV ��RI�WDVNV

x < -100 0 0-100 < x < -50 11 12.95-50 < x < -20 11 12.95-20 < x < 0 7 8.25x = 0 8 9.450 < x < +20 14 16.45+20 < x < +50 4 4.70+50 < x < +100 27 31.75x > +100 3 3.5

7RWDO ��

7DEOH��'LVWULEXWLRQ�RI�HUURUV�LQ�WKH�SUHGLFWLRQ

From these results it can be seen that, although the task durations were predicted withlimited success, this is due to the difficulties experienced in observing the durations ofcovert activities. Specifically, the covert tasks were difficult to observe and theobserved durations had to be estimated. For overt activities, however, the resultsappeared to be more promising as 60.5% of overt tasks were predicted to within amargin of +/- 20%, compared to 12.8% of covert tasks. This is illustrated in Table 10.

2YHUW�WDVNV &RYHUW�WDVNV

&OXVWHU 1XPEHU�RI�WDVNV ��RI�WDVNV 1XPEHU�RI�WDVNV ��RI�WDVNV

x < -100 0 0 0 0-100 < x < -50 6 15.79 5 10.64-50 < x < -20 6 15.79 5 10.64-20 < x < 0 6 15.79 1 2.13x = 0 4 10.53 4 8.510 < x < +20 13 34.21 1 2.13+20 < x < +50 3 7.90 1 2.13+50 < x < +100 0 0 27 57.45x > +100 0 0 3 6.38

7RWDO ��

7DEOH��'LVWULEXWLRQ�RI�HUURUV�LQ�WKH�SUHGLFWLRQ�IRU�RYHUW�YV�FRYHUW�WDVNV



(852&21752/

It is concluded, therefore, that the potential to predict task durations, particularly forovert activities, is the main strength of the methodology.

�� 3UHGLFWHG�6HTXHQFH�2I�$FWLYLW\

To assess the accuracy of the methodology in predicting controller activity, thepredicted sequence of phases (see Table 5) were compared with the observed phasesequences derived from analysis of the predicted time period on the video. The analysiswas performed at phase level as opposed to task level as it was not possible to derivetask information from the video in the time available.

To facilitate comparison, both sequences were plotted graphically as shown in Figure 2in Appendix E.

From the analysis, some similarities and some differences were noted in the predictedand observed phase sequences. These are summarised in Table 11 to Table 13 below.

3KDVH 3UHGLFWHG 2EVHUYHG

� Not included in task model butrepresents adjustment of headingsto keep an aircraft in the airway.

Phase not included in taskmodel so not predicted.

10 instances observed.

� Deal with incoming aircraft. 6 instances predictedthroughout sequence.

6 instances observedthroughout sequence.

� Deal with outgoing aircraft. 4 instances predictedthroughout sequence.


� Monitoring. 27 instances predictedthroughout sequence.


� Formulate plan with Planner(Short Term).

6 instances predictedthroughout sequence.

1 instance observedearly in sequence.

� Formulate plan by self (ShortTerm).

0 instances predicted. 6 instances observedthroughout sequence.

� Formulate plan with Planner(Long Term).

3 instances predictedthroughout sequence.

0 instances observed.

� Formulate plan by self (LongTerm).

0 instances predicted. 0 instances observed.

� Implement conflict resolutionplan.

6 instances predicted earlyin sequence.

6 instances observedlate in sequence.

� Issue routine instructions. 6 instances predictedthroughout sequence.


�� Assess implications of changingaircraft parameter.

10 instances predicted. 0 instances observed.

�� Housekeeping. 6 instances predictedthroughout sequence.


7DEOH��3UHGLFWHG�YV�2EVHUYHG�2FFXUUHQFHV�2I�3KDVHV



(852&21752/

&RUUHFW�3UHGLFWLRQV

Number and timing of instances of Phase 1 (Deal withincoming aircraft) predicted correctly.Number and timing of instances of Phase 3(Monitoring) predicted correctly (approximately).No observed or predicted occurrences of Phase 7(Formulate plan by self (Long term)).Number and timing of instances of Phase 8(Implement conflict resolution plan) predictedcorrectly.

7DEOH��6XPPDU\�2I�&RUUHFW�3UHGLFWLRQV

,QFRUUHFW�3UHGLFWLRQV 6RXUFH�2I�(UURU��5HIHUHQFH�7DEOH��

Phase 0 (Tuning an aircraft’s heading to keep it inthe airway) is not predicted to occur.

Task breakdown in task model does notcapture this activity �5HI��.

More instances of the following were observed thanwere predicted:• Phase 2 (Deal with outgoing aircraft)• Phase 5 (Formulate plan by self (Short term))• Phase 9 (Issue routine instructions)

Heuristics are over simplistic �5HI��.Controller will re-visit conflict resolutionphases after an interruption yet this is notcaptured within the task model �5HI��.Scenario model may be incorrect �QRUHIHUHQFH��

Fewer instances of the following were observed thanwere predicted:• Phase 4 (Formulate plan with Planner (Short

term))• Phase 6 (Formulate plan with Planner (Long

term))• Phase 10 (Assess implications of changing an

aircraft parameter)• Phase 11 (Housekeeping)

Heuristics are over simplistic �5HI��.Phase 10 is highly covert and could not bedetected from observation of the video �QRUHIHUHQFH�.Scenario model may be incorrect �QRUHIHUHQFH��

Different solutions selected in Phase 8 (Implementconflict resolution plan).

Selection rules for conflict resolution areover simplistic �5HI��.Scenario model may be incorrect �QRUHIHUHQFH��

Simultaneous task performance observed but notpredicted

Simultaneous task performance is notcaptured within the selection rules in the taskmodel �5HI��.

Modification of conflict resolution strategies occursbut is not predicted.

Task model does not reflect fact thatalternative strategies for conflict resolutionmay be adopted by the controller if theoriginal strategy is believed to be ineffective�5HI��.

Planner observed to assist Tactical in some tasks,but this is not predicted.

Task model does not capture the sharing oftasks between the Tactical and Plannercontrollers �5HI��.

7DEOH��6XPPDU\�2I�,QFRUUHFW�3UHGLFWLRQV

As shown in Table 13, most of the likely reasons for errors in the prediction wereanticipated during Stage 2 of the work programme, and are listed in Table 7. Theserelate primarily to deficiencies in the task model, and consequently are likely to be



(852&21752/

contributory factors in all the noted deviations between observed and predictedperformance. In addition, some of the errors may be due to practical difficultiesexperienced during the analysis. Specifically, for phases which feature more during thepredicted performance than the observed (e.g. Phase 10- Assess implications ofchanging an aircraft parameter), the difference is likely to be due to the fact that theactivity involved has a large covert component and is, therefore, difficult to detect fromobservation of the video.

The fact that the errors in the prediction were anticipated and can be explained byknown weaknesses within the task model suggests that there are no fundamentalproblems with the approach. Consequently, it is likely that by addressing thelimitations described above, the predictive capability of the methodology could beimproved. Specifically, the task model should be developed to support more accurateperformance prediction.

�� 3UHGLFWHG�&RQWUROOHU�:RUNORDG

To assess the accuracy of the methodology in predicting controller workload, thepredicted workload levels were compared with the observed levels, as indicated byobjective measures on the video (described below). To facilitate comparison, thedifferent measures of workload were plotted graphically as shown in Figures 3 to 6 inAppendix E. In these figures, each predicted measure was compared with eachobserved measure. The predicted and observed levels used in the comparison aredescribed below.

�� 3UHGLFWHG�:RUNORDG�0HDVXUHV

Predicted workload was assessed using two summary measures. These aredescribed below.

• 3UHGLFWHG�ZRUNORDG��+LJKV�DQG�ORZV�� This is a measure showing thepredicted highs and lows in workload levels, as shown in Table 6. These areplotted in Figures 3 and 4 in Appendix E to the nearest 10 seconds.Instances at which the workload is neither high or low are plotted against theneutral workload value of 3.

• 3UHGLFWHG�ZRUNORDG��$YHUDJH�RYHU��VHFRQG�LQWHUYDO�� This is a measureshowing, at 10 second intervals, the average predicted workload over theprevious 10 seconds. It is plotted in Figures 5 and 6 (Appendix E).

�� 2EVHUYHG�:RUNORDG�0HDVXUHV

Observed workload was assessed using two objective measures. These aredescribed below.

• 2EVHUYHG�ZRUNORDG��EDVHG�RQ��WLPH�RQ�$70�WDVNV�� The proportion oftime the controller was occupied with ATM tasks was taken as an objectiveindication of workload levels. As such, 100% occupation was taken toindicate high workload (and was plotted as a workload value of 5) and 0%



(852&21752/

occupation was taken to indicate low workload (and was plotted as aworkload value of 0). This is illustrated in Table 14 below.

��2FFXSDQF\ :RUNORDG�9DOXH100 580 460 340 220 10 0

7DEOH��2EVHUYHG�:RUNORDG��EDVHG�RQ��WLPH�RQ�$70�WDVNV�

In the absence of other indications, this measure was based on the proportion ofeach 10 second time interval for which the controller was engaged in non ATMtasks, as indicated by irrelevant comments and discussions. This measure isplotted in Figure 3 and Figure 5 in Appendix E.

• 2EVHUYHG�ZRUNORDG��EDVHG�RQ�QR��57�WUDQVPLVVLRQV�� A second objectiveindication of workload used in the analysis was the number of RTtransmissions made and received by the controller in each 10 second timeperiod. This was recorded through analysis of the video, and the numbersrecorded ranged from 0 to 8 transmissions. To allow comparison with theother measures of workload, these values were scaled down to a 5 pointscale. For example, time periods containing the maximum of 8transmissions were plotted against the maximum workload value of 5. Thismeasure is plotted in Figure 4 and Figure 6 in Appendix E.

�� &RPSDULVRQV

From the figures in Appendix E, it can be seen that there are both similaritiesand differences in the predicted and observed levels of workload. These aresummarised in Table 15 below.

&RUUHFW�3UHGLFWLRQV ,QFRUUHFW�3UHGLFWLRQV

• Most of the predicted instances of highworkload occurred within periods ofobserved high workload.

• Few of the instances of observed lowworkload were predicted.

• Observed workload was generally higherthan predicted workload.

• The variability in workload levels was notaccurately predicted.

7DEOH��6XPPDU\�2I�:RUNORDG�3UHGLFWLRQ

The errors in the predicted workload levels, as compared to the objectivemeasures used in the analysis, can be explained by the following:• The methodology cannot accurately predict controller activity.

Consequently, since the workload prediction is necessarily dependent uponthe accuracy of the predicted activity, and there are errors in the predicted



(852&21752/

phase sequence (see Section 4.2), errors in the predicted workload areinevitable.

• The task model does not adequately capture simultaneous task performance.This is essential to the correct prediction of workload, and is the probablereason why observed workload was generally higher that predicted workload.

In addition, the errors may also be explained by limitations in the data availablefor comparison purpose. Specifically, there is no suitable objective measure ofobserved workload available from analysis of the video alone. The problemsassociated this are illustrated below.• It is indicated in Figures 4 and 6 (Appendix E), that a weakness of the

methodology is in its failure to reliably predict low levels of workload.However, this may be because the low levels of observed workload in thesefigures represent periods during which the RT load is low. This does notreflect the fact that workload can be high, in the absence of RT, due tocognitive loading from other task demands.

• It is also indicated, in Figures 3 and 5 (Appendix E), that predicted workloadis generally lower than observed workload. However, in these cases highworkload is indicated by the proportion of time spent engaged in ATM tasks.Inherent in this is the assumption that all ATM tasks have the same effect onworkload. The inappropriateness of this assumption may explain the failureof the methodology to predict workload when it is measured in this way.


&RQFOXVLRQV��)XUWKHU�:RUN ��

(852&21752/

�� &21&/86,216��)857+(5�:25.

�� &RQFOXVLRQV

From this work programme, it can be seen that the main strength of the methodology isits potential to predict task durations, particularly for overt activities. In contrast to this,the performance of the methodology in predicting controller strategy and workload wasdisappointing. However, this appears to be due to problems, not with the methodologyitself, but with the task model and the heuristics which had to be applied in the absenceof more accurate scenario information.

Specifically, though there was some degree of accuracy in the predicted performance,there were errors in the predicted number and timing of some tasks. These errors mainlyrelate to the use of heuristics and deficiencies in the task model. The heuristics wereassumptions regarding scenario details which, in the absence of accurate scenarioinformation, were essential for the prediction of performance. Although attempts weremade to ensure that the heuristics would produce the most accurate prediction, it wasinevitable that the assumptions were not true in every case. The deficiencies in the taskmodel related mainly to the task selection rule base such that the rules were unable tocapture accurately the simultaneous performance of tasks, and were over simplistic in thecase of conflict resolution activities.

There were also errors in the predicted workload levels. Again, these do not indicateproblems with the methodology, but are the result of data limitations and deficiencies inthe task model. Specifically, the accurate prediction of workload levels depend upon theaccuracy of the predicted sequence of activity. As the activity sequence was notpredicted accurately in this work programme (due to deficiencies in the task model andscenario data limitations, described above), inaccuracies in the workload prediction wereinevitable. An additional cause of the apparent inaccuracy of the predicted workloadlevels is the absence of a suitable objective measure of observed workload. This meansthat the predictive capability of the methodology with respect to workload could not beadequately assessed in this work programme.

In addition, the results are likely to be adversely affected by the fact that the predictedsequence was only 10 minutes in duration. This imposed limitations on the range ofactivities that could be performed by the controller.

It is concluded, therefore, that the methodology does have the potential to be a useful toolwithin ATM research, providing the task model and scenario model are accurate. Inproviding a means of predicting performance and workload, it can support the earlyintegration of human factors into the design process. In some areas, the prediction ofperformance and workload was successful, and where this was not the case, the reasonsbehind the errors were anticipated and related to deficiencies within the task model andto data limitations. Together these acted to obstruct the validation process as theyproduced errors in the predictions that are not likely to be attributable to problems withthe methodology itself. Consequently, it is suggested that these are addressed throughfurther development of the task model and by obtaining, for use throughout the analysis,more detailed scenario information than was available from the video. This would allowa more effective validation of the methodology to be undertaken.


�� &RQFOXVLRQV��)XUWKHU�:RUN

(852&21752/

Recommendations for further work are given below.

�� 5HFRPPHQGDWLRQV

It is recommended that further work be conducted to improve the methodology andaddress the problems in the task model and subsequently, that a more effective validationof the methodology is undertaken.

Initially, the methodology needs to be developed further through the preparation of aposition paper based on discussions held between Human Engineering, Eurocontrol andNATS in December 1998. Specifically, the structure of the methodology and its role inthe design process should be clarified. This should address the activities included withinthe methodology and the goals towards which it is oriented.

Subsequently, an approach for improving the methodology should be developed. Thisshould include the specification of a suitable approach for developing the task model toaddress the limitations identified in this study. In particular, the task model should bedeveloped to address the deficiencies identified in this work, particularly within theselection rules. This should focus on improving the extent to which simultaneous taskperformance is captured, and on developing the selection rules, particularly for conflictresolution. It is likely that this work would involve direct observation of controllers anduse of verbal protocol techniques to capture cognitive functioning during taskperformance. In addition, a means of obtaining improved scenario data should bedetermined.

Following this, before further validation can be carried out, the problems with thevalidation process should be resolved. Specifically, an appropriate objective measure ofworkload should be identified and shown to be available. In addition, a means ofobtaining temporal data for covert tasks should be ascertained.

Only when the above stages are complete should a second validation process beperformed. Ideally, this should involve a dedicated trial, designed and run to meet thespecific requirements of the validation. The additional control over the scenario and datacollection that this would provide would enable a more effective and reliable test of themethodology.


5HIHUHQFHV ��

(852&21752/

�� 5()(5(1&(6

1. /RFNHWW��-��)��Task Network Modelling Of Human Workload Coping Strategies.U.S. Army Research Laboratory, Maryland, United States.

2. Hamilton, W. I. & Cullen, E. (1998) 'HYHORSPHQW�2I�7KH�4H�0RGHO�)RU�:RUNORDG

3UHGLFWLRQ� Unpublished paper: Human Engineering Limited. 3. Schuck, M. M. (1990) $�1HZ�0HWKRG�)RU�7KH�'HYHORSPHQW�2I�7DVN�&RQIOLFW�0DWULFHV.

Unpublished paper: Defence & Civil Institute Of Environmental Medicine, USA. 4. Hick, W. (1952) 2Q�7KH�5DWH�2I�*DLQ�2I�,QIRUPDWLRQ�� Quarterly Journal Of

Experimental Psychology, 4, 11-26. 5. Fitts, P. (1954) 7KH�,QIRUPDWLRQ�&DSDFLW\�2I�7KH�+XPDQ�0RWRU�6\VWHP�,Q�&RQWUROOLQJ

7KH�$PSOLWXGH�2I�0RYHPHQW� Journal Of Experimental Psychology, 47, 381-391. 6. Fitts, P. & Peterson, J. (1964)��,QIRUPDWLRQ�&DSDFLW\�2I�'LVFUHWH�0RWRU�5HVSRQVHV�

Journal Of Experimental Psychology, 67, 103-112. 7. Card, S. K., Moran, T. P. & Newell, A (1983) 7KH�3V\FKRORJ\�2I�+XPDQ�&RPSXWHU

,QWHUDFWLRQ� Lawrence Erlbaum Associates: New Jersey.

8. Sternberg, S., Monsell, S., Knoll, R. L. & Wright, C. E. (1978) 7KH�/DWHQF\�$QG�'XUDWLRQ2I�5DSLG�0RYHPHQW�6HTXHQFHV��&RPSDULVRQV�2I�6SHHFK�$QG�7\SHZULWLQJ� InStelmach, G. E. Information Processing In Motor Control And Learning, New YorkAcademic Press.


�� 5HIHUHQFHV

(852&21752/



$�� $SSHQGL[�$

(852&21752/

��

�� !��


$SSHQGL[�$ $��

(852&21752/


9DOLGDWLRQ�RI�D�0

HWKRGRORJ\�IRU�3UHGLFWLQJ�3HUIRUP

DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

Mis

sion

: E

nsur

e sa

fe p

assa

ge o

f ai

rcra

ft th

roug

h se

ctor

��

��

��

��

��

��

��

Dea

l with

inco

min

g a/

cD

eal w

ithou

tgoi

ng a

/cM

onito

ring

Form

ulat

epl

an w

ithpl

anne

r (S

T)

Form

ulat

epl

an b

y se

lf(S

T)

Form

ulat

epl

an w

ithpl

anne

r(L

T)

Form

ulat

epl

an b

y se

lf(L

T)

Impl

emen

tco

nflic

tre

solu

tion

plan

Issu

e ro

utin

ein

stru

ctio

nsA

sses

sim

plic

atio

nsof

cha

ngin

ga/

c pa

ram

eter

Hou

seke

epin

gL

iase

with

adja

cent

sec

tor



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

1D

eal w

ith

inco

min

gai

rcra

ft

1.1

Iden

tify

a/c

calli

ng in

1.2

Acc

ept a

/c o

nfr

eque

ncy

1.3

Ass

ess

new

a/c

1.1.

1L

iste

n to

a/c

calli

ng in

1.1.

2Sc

an r

adar

for

corr

ect T

DB

1.1.

3D

eter

min

ere

quir

edac

tion

1.2.

1A

ccep

t a/c

(RT

)

1.2.

2E

dit T

DB

1.3.

1E

xam

ine

a/c

FL

1.3.

2D

eter

min

ere

quir

edac

tion



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

2D

eal w

ith

outg

oing

a/c

2.1

Rel

ease

a/c

(tr

ansf

er)

2.1.

1R

elea

se a

/c (

RT

) (t

rans

fer)

2.1.

2E

dit T

DB



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

3M

onit

orin

g

3.1

Det

erm

ine

focu

sfo

r m

onito

ring

3.2

Det

erm

ine

if an

ya/

c re

quir

ere

leas

ing

(tra

nsfe

r)

3.3

Ass

ess

indi

vidu

al a

/cre

quir

emen

ts

3.4

Iden

tify

poss

ible

conf

licts

(S

T)

3.5

Iden

tify

poss

ible

conf

licts

(ST

& L

T)

3.6

Ass

ess

conf

lict

aler

t

3.1.

1A

sses

sde

gree

of

conf

lict

3.1.

2D

eter

min

ere

quir

emen

tto

hous

ekee

p

3.1.

3R

evie

w a

irpi

ctur

e

3.1.

4D

eter

min

ere

quir

edac

tion

3.3.

1G

athe

r in

foon

FL

3.3.

2D

eter

min

ere

quir

edac

tion

3.3.

3G

athe

r in

foon

hdg

3.3.

4D

eter

min

ere

quir

edac

tion

3.5.

1G

athe

r in

foon

tra

ffic

3.5.

2D

eter

min

ere

quir

edac

tion

3.2.

1G

athe

r in

fo o

nou

tbou

nd a

/c

3.2.

2D

eter

min

ere

quir

ed a

ctio

n

3.4.

1G

athe

r in

fo o

ntr

affic

3.4.

2D

eter

min

ere

quir

ed a

ctio

n

3.6.

1G

athe

r in

fo o

nco

nflic

ting

a/c

3.6.

2D

eter

min

ere

quir

ed a

ctio

n



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

4Fo

rmul

ate

plan

wit

h pl

anne

r (S

T)

4.1

Gat

her

info

rmat

ion

4.2

Sele

ct c

onfl

ict r

esol

utio

n pl

an

4.1.

1G

athe

r in

fo o

ntr

affi

c fr

omT

DB

s

4.1.

2D

iscu

ss c

onfl

ict

with

pla

nner

4.1.

3D

eter

min

e ty

peof

con

flic

t

4.2.

1A

sses

sfe

asib

ility

of

optio

ns

4.2.

2D

eter

min

ere

quir

ed a

ctio

n



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

5Fo

rmul

ate

plan

by

self

(ST

)

5.1

Gat

her

info

rmat

ion

5.2

Sele

ct c

onfl

ict r

esol

utio

n pl

an

5.1.

1G

athe

r in

fo o

ntr

affi

c fr

omT

DB

s

5.1.

2D

eter

min

e ty

peof

con

flic

t

5.2.

1A

sses

sfe

asib

ility

of

optio

ns

5.2.

2D

eter

min

ere

quir

ed a

ctio

n



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

6Fo

rmul

ate

plan

wit

h pl

anne

r (L

T)

6.1

Gat

her

info

rmat

ion

6.2

Sele

ct c

onfl

ict r

esol

utio

n pl

an

6.1.

1A

sses

sde

gere

e of

clut

ter

6.1.

2D

eter

min

ere

quir

emen

tto

hou

seke

ep

6.1.

3G

athe

r in

foon

traf

fic

from

TD

Bs

6.1.

4G

athe

r in

foon

traf

fic

from

tool

s

6.1.

5D

iscu

ssop

tions

with

plan

ner

6.1.

6D

eter

min

ety

pe o

fco

nflic

t

6.2.

1A

sses

sfe

asib

ility

of

optio

ns

6.2.

2D

eter

min

ere

quir

edac

tion



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

7Fo

rmul

ate

plan

by

self

(L

T)

7.1

Gat

her

info

rmat

ion

7.2

Sele

ct c

onfl

ict r

esol

utio

n pl

an

7.1.

1A

sses

sde

gere

e of

clut

ter

7.1.

2D

eter

min

ere

quir

emen

tto

hou

seke

ep

7.1.

3G

athe

r in

foon

traf

fic

from

TD

Bs

7.1.

4G

athe

r in

foon

traf

fic

from

tool

s

7.1.

5D

eter

min

ety

pe o

fco

nflic

t

7.2.

1A

sses

sfe

asib

ility

of

optio

ns

7.2.

2D

eter

min

ere

quir

edac

tion



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

8Im

plem

ent c

onfl

ict r

esol

utio

n pl

an

8.1

Cha

nge

hdg

tore

solv

eco

nflic

t (1

a/c)

8.2

Cha

nge

FL to

reso

lve

conf

lict (

1 a/

c)

8.3

Res

tric

t/ch

ange

spe

edto

res

olve

conf

lict

8.4

Put

bot

h a/

c on

hdgs

to r

esol

veco

nflic

t (2

a/c)

8.5

Stop

clim

b /

desc

ent o

f a/

c to

reso

lve

conf

lict

(1a/

c)

8.6

Stop

clim

b /

desc

ent o

fbo

th a

/c to

reso

lve

conf

lict

8.2.

1C

hang

e FL

(RT

)

8.2.

2E

dit T

DB

8.4.

1C

hang

e hd

g(a

/c1)

(R

T)

8.4.

2E

dit T

DB

(a/c

1)

8.4.

3C

hang

e hd

g(a

/c2)

(R

T)

8.4.

4E

dit T

DB

(a/c

2)

8.5.

1St

op c

limb/

desc

ent

(RT

)

8.5.

2E

dit T

DB

8.1.

1C

hang

ehd

g (R

T)

8.1.

2E

dit T

DB

8.3.

1R

eque

stsp

eed

info

(a/c

1) (

RT

)

8.3.

2R

eque

stsp

eed

info

(a/c

2) (

RT

)

8.3.

3R

estr

ict/

chan

gesp

eed

(a/c

2) (

RT

)

8.3.

4E

dit T

DB

(a/c

2)

8.3.

5R

estr

ict/

chan

gesp

eed

(a/c

1) (

RT

)

8.3.

6E

dit T

DB

(a/c

1)

8.6.

1St

op c

limb/

desc

ent

(a/c

1) (

RT

)

8.6.

2E

dit T

DB

(a/c

1)

8.6.

3St

op c

limb/

desc

ent

(a/c

2) (

RT

)

8.6.

4E

dit T

DB

(a/c

2)



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

9Is

sue

rout

ine

inst

ruct

ions

9.1

Cha

nge

FL to

XFL

9.2

Cha

nge

FL to

inte

rim

FL

9.3

Put

a/c

on

own

navi

g

9.1.

1C

hang

e FL

(RT

)

9.1.

2E

dut T

DB

9.2.

1C

hang

e FL

(RT

)

9.2.

2E

dit T

DB

9.3.

1P

ut a

/c o

n ow

nna

vig

(RT

)

9.3.

2E

dit T

DB



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

10A

sses

s im

plca

tion

s of

cha

ngin

g a/

cpa

ram

eter

10.1

Ass

ess

impl

icat

ions

of

chan

ging

FL

10.2

Ass

ess

impl

icat

ions

of

putt

ing

a/c

on o

wn

navi

gatio

n

10.1

.1A

sses

sde

gree

of

clut

ter

10.1

.2D

eter

min

ere

quir

emen

tto

hou

seke

ep

10.1

.3G

athe

r in

foon

traf

fic

10.1

.4D

eter

min

ere

quir

edac

tion

10.2

.1A

sses

sde

gree

of

clut

ter

10.2

.2D

eter

min

ere

quir

emen

tto

hou

seke

ep

10.2

.3G

athe

r in

foon

traf

fic

10.2

.4D

eter

min

ere

quir

edac

tion



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

11H

ouse

keep

ing

11.1

Tid

y T

DB

s

11.1

.1M

ove

TD

Bs



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

12L

iase

wit

h ad

jace

nt s

ecto

r

12.1

Lia

se w

ith a

djac

ent s

ecto

r

12.1

.1T

alk

with

adj

acen

tse

ctor



DQFH��:

RUNORDG

$SSHQGL[�$

��$��

(852&21752/

Inte

ntio

nally

left

bla

nk


$SSHQGL[�$ ��$��

��

HEL/EC/97152/RT3 Issue: 01

Function

Task

1

1.1

1.1.1

Identify a/c calling in

Listen to a/c calling in

Deal with incoming a/cPhase

3.0Predicted duration 2.9Observed duration

a/c calls in External initiating conditionsExternalInitiation category

+1 a/c on frequencyEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 1.1.2 - Scan radar for correct TDB

Selection Rules

TASK MODEL

V A C PListen to a/c Interpret SpeechBEHAVIOURS

Task Interruptibility Yes

HighFunction PriorityYesFunction Interruptibility

04/02/98 Annex A


Function

Task

1

1.1

1.1.2


Scan radar for correct TDB



External initiating conditionsFollow onInitiation category

n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 1.1.3 - Determine required action

Selection Rules

TASK MODEL

V A C PLocate TDB

Read TDB (call sign)

Compare TDB call sign with stated call sign

Search

Text Symbology

Compare Identity Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

1

1.1

1.1.3


Determine required action



External initiating conditionsRule basedInitiation category

n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 1.2.1 - Accept a/c (RT) & 1.2.2 - Edit TDB

Selection Rules

TASK MODEL

V A C PDetermine required action DecideBEHAVIOURS



04/02/98 Annex A


Function

Task

1

1.2

1.2.1

Accept a/c on frequency

Accept a/c (RT)




n/aEffect

Concurrent with 1.2.2 - Edit TDBSelection Rules

TASK MODEL

V A C PActivate RT

Talk to a/c

Reach/Switch

Speak

BEHAVIOURS

Task Interruptibility No

HighFunction PriorityNoFunction Interruptibility

04/02/98 Annex A


Function

Task

1

1.2

1.2.2

Accept a/c on frequency

Edit TDB




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (a/c released by previous sector): 1.3.1 - Examine a/c FLIf (CA not initiated) & (0 a/c calling in) & (a/c not released by previous sector): 12.1.1 - Talk with adjacent sector

Selection Rules

TASK MODEL

V A C PSelect 'assume' from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

1

1.3

1.3.1

Assess new a/c

Examine a/c FL




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 1.3.2 - Determine required action

Selection Rules

TASK MODEL

V A C PRead TDB (FL info)

Compare AFL with XFL

Text Symbology

Compare Identity

BEHAVIOURS


LowFunction PriorityYesFunction Interruptibility

04/02/98 Annex A


Function

Task

1

1.3

1.3.2

Assess new a/c





n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (AFL not = XFL): 10.1.1 of Function 10.1 - Assess implications of changingFLIf (CA not initiated) & (0 a/c calling in) & (AFL = XFL) & (WL = High): 3.4.1 of Function 3.4 - Identify possibleconflicts (Short term)If (CA not initiated) & (0 a/c calling in) & (AFL = XFL) & (WL = Low): 3.5.1 of Function 3.5 - Identify possibleconflicts (Short & long term)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

2

2.1

2.1.1

Release a/c (transfer)

Release a/c (RT) (transfer)

Deal with outgoing a/cPhase



-1 a/c on frequencyEffect


TASK MODEL

V A C PActivate RT

Talk to a/c (Contact XXXX)

Listen to a/c Interpret Speech

Reach/Switch

Speak

BEHAVIOURS


LowFunction PriorityNoFunction Interruptibility

04/02/98 Annex A


Function

Task

2

2.1

2.1.2

Release a/c (transfer)

Edit TDB

Deal with outgoing a/cPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Function -1 = 3.2) & ((no. unreleased TDBs near edge at start of cycle) > (no.times Task 3.2.1 performed in cycle)): 3.2.1 - Gather info on outbound a/cIf (CA not initiated) & (0 a/c calling in) & (Function -1 = 3.2) & ((no. unreleased TDBs near edge at start of cycle) <=(no. times Task 3.2.1 performed in cycle)): 3.1.1 of Function 3.1 - Determine focus for monitoringIf (CA not initiated) & (0 a/c calling in) & (Function -1 = 12.1.1) & ((no. unreleased TDBs near edge at start of cycle) >(no. times Task 3.2.1 performed in cycle)): 3.2.1 - Gather info on outbound a/cIf (CA not initiated) & (0 a/c calling in) & (Function -1 = 12.1.1) & ((no. unreleased TDBs near edge at start of cycle) <=(no. times Task 3.2.1 performed in cycle)): 3.1.1 of Function 3.1 - Determine focus for monitoring

Selection Rules

TASK MODEL

V A C PSelect 'release' from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.1

3.1.1

Determine focus for monitoring

Assess degree of clutter

MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 3.1.2 - Determine requirement to housekeep

Selection Rules

TASK MODEL

V A C PLook at PVD


Inspect/Check

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.1

3.1.2


Determine requirement to housekeep

MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (clutter = high): 11.1.1 - Move TDBsIf (CA not initiated) & (0 a/c calling in) & (clutter = low): 3.1.3 - Review air picture

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.1

3.1.3


Review air picture

MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD

Review mental model

Inspect/Check

Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.1

3.1.4



MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge > 0) & (t since last Task 3.2.1 >60sec): 3.2.1 -Gather info on outbound a/cIf (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge > 0) & (t since last Task 3.2.1 <=60sec) & (tsince last Task 3.3.1 >60sec): 3.3.1 of Function 3.3 - Assess individual a/c requirementsIf (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge > 0) & (t since last Task 3.2.1 <=60sec) & (tsince last Task 3.3.1 <=60sec) & (WL = High): 3.4.1 of Function 3.4 - Identify possible conflicts (Short term)If (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge > 0) & (t since last Task 3.2.1 <=60sec) & (tsince last Task 3.3.1 <=60sec) & (WL = Low): 3.5.1 of Function 3.5 - Identify possible conflicts (Short & long term)If (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge = 0) & (t since last Task 3.3.1 >60sec): 3.3.1of Function 3.3 - Assess individual a/c requirementsIf (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge = 0) & (t since last Task 3.3.1 <=60sec) &(WL = High): 3.4.1 of Function 3.4 - Identify possible conflicts (Short term)If (CA not initiated) & (0 a/c calling in) & (no. unreleased TDBs near edge = 0) & (t since last Task 3.3.1 <=60sec) &(WL = Low): 3.5.1 of Function 3.4 - Identify possible conflicts (Short & long term)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.2

3.2.1

Determine if any a/c require releasing (transfer)

Gather info on outbound a/c

MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead outbound TDB near edge of sector

Check AFL = XFL

Check a/c not on hdg

Check a/c accepted by next sector

Text Symbology

Inspect/Check

Inspect/Check

Inspect/Check

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.2

3.2.2

Determine if any a/c require releasing (transfer)


MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (AFL = XFL) & (a/c not on hdg) & (a/c accepted by next sector): 2.1.1 -Release a/c (RT) (transfer) & 2.1.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (AFL = XFL) & (a/c not on hdg) & (a/c not accepted by next sector): 12.1.1 -Talk with adjacent sectorIf (CA not initiated) & (0 a/c calling in) & (AFL not= XFL): 10.1.1 of Function 10.1 - Assess implications of changingFLIf (CA not initiated) & (0 a/c calling in) & (AFL = XFL) & (a/c on hdg): 10.2.1 of Function 10.2 - Assess implications ofputting a/c on own navigation

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.3

3.3.1

Assess individual a/c requirements

Gather info on FL

MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead TDB (FL info)

Compare AFL with XFL

Text Symbology

Compare Identity

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.3

3.3.2



MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (AFL = XFL): 3.3.3 - Gather info on HdgIf (CA not initiated) & (0 a/c calling in) &(AFL not = XFL): 10.1.1 of Function 10.1 - Assess implications of changingFL

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.3

3.3.3


Gather info on Hdg

MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead TDB (Hdg info)

Determine if a/c on a heading

Text Symbology

Recognise

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.3

3.3.4



MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (a/c on hdg): 10.2.1 of Function 10.2 - Assess implications of putting a/con own navigationIf (CA not initiated) & (0 a/c calling in) & (a/c not on hdg) & (((no. a/c on hdg at start of cycle) > (no. times Task 3.3.1performed in cycle)) OR ((no. a/c AFL not= XFL at start of cycle) > (no. times Task 3.3.1 performed in cycle))): 3.3.1 ofFunction 3.3 - Assess individual a/c requirementsIf (CA not initiated) & (0 a/c calling in) & ((no. a/c on hdg at start of cycle) <= (no. times Task 3.3.1 performed in cycle))& ((no. a/c AFL not= XFL at start of cycle) <= (no. times Task 3.3.1 performed in cycle)): 3.1.1 of Function 3.1 -Determine focus for monitoring

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.4

3.4.1

Identify possible conflicts (Short term)

Gather info on traffic

MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Determine if there are any possible conflicts

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.4

3.4.2

Identify possible conflicts (Short term)


MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Conflict = 0): 3.1.1 of Function 3.1 - Determine focus for monitoringIf (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (PC available): 4.1.1 of Phase 4 - Formulate plan withPlanner (Short term)If (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (PC not available): 5.1.1 of Phase 5 - Formulate plan by self(Short term)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.5

3.5.1

Identify possible conflicts (Short & long term)


MonitoringPhase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Determine if there are any possible conflicts

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

3

3.5

3.5.2

Identify possible conflicts (Short & long term)


MonitoringPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Conflict = 0): 3.1.1 of Function 3.1 - Determine focus for monitoringIf (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (WL = High) & (PC available): 4.1.1 of Phase 4 - Formulateplan with Planner (Short term)If (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (WL = High) & (PC not available): 5.1.1 of Phase 5 -Formulate plan by self (Short term)If (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (WL = Low) & (PC available): 6.1.1 of Phase 6 - Formulateplan with Planner (Long term)If (CA not initiated) & (0 a/c calling in) & (Conflict >0) & (WL = Low) & (PC not available): 7.1.1 of Phase 7 - Formulateplan by self (Long term)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

3

3.6

3.6.1

Assess conflict alert

Gather info on conflicting a/c

MonitoringPhase


Conflict alert activatedExternal initiating conditionsExternalInitiation category

n/aEffect

3.6.2 - Determine required actionSelection Rules

TASK MODEL

V A C PRead TDBs for conflicting a/c

Review mental model

Determine if conflict is true

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS


UrgentFunction PriorityNoFunction Interruptibility

04/02/98 Annex A


Function

Task

3

3.6

3.6.2

Assess conflict alert


MonitoringPhase



n/aEffect

If (Conflict is false) & (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (Conflict is false) & (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (Conflict is false) & (CA not initiated) & (0 a/c calling in) & (Function -1 interruptible): Task-2If (Conflict is false) & (CA not initiated) & (0 a/c calling in) & (Function -1 not interruptible): 3.1.1 of Function 3.1 -Determine focus for monitoringIf (Conflict is true) & (PC available): 4.1.1 of Phase 4 - Formulate plan with Planner (Short term)If (Conflict is true) & (PC not available): 5.1.1 of Phase 5 - Formulate plan by self (Short term)

Selection Rules

TASK MODEL



UrgentFunction PriorityNoFunction Interruptibility

04/02/98 Annex A


Function

Task

4

4.1

4.1.1

Gather information

Gather info on traffic from TDBs

Formulate plan with Planner (Short term)Phase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 4.1.2 - Discuss conflict with Planner

Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Text Symbology

Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

4

4.1

4.1.2

Gather information

Discuss conflict with Planner




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 4.1.3 - Determine type of conflict

Selection Rules

TASK MODEL

V A C PTalk to Planner

Listen to Planner Interpret Speech

SpeakBEHAVIOURS



04/02/98 Annex A


Function

Task

4

4.1

4.1.3

Gather information

Determine type of conflict




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 4.2.1 - Assess feasibility of options

Selection Rules

TASK MODEL

V A C PDetermine type of conflict JudgeBEHAVIOURS



04/02/98 Annex A


Function

Task

4

4.2

4.2.1

Select conflict resolution plan

Assess feasibility of options




n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD

Read TDBs

Review mental model

Assess possibility of conflicts

Inspect/Check

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

4

4.2

4.2.2






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Conflict type = crossing) & (hdg change not prohibited by traffic): 8.1.1 ofFunction 8.1 - Change Hdg to resolve conflict (1 a/c) & 8.1.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (CA not initiated) & ((Conflict type = crossing) OR (Conflict type = head-on)) &(hdg change prohibited by traffic) & (2 a/c level): 8.2.1 of Function 8.2 - Change FL to resolve conflict (1 a/c) & 8.2.1- Edit TDBIf (CA not initiated) & (0 a/c calling in) & ((Conflict type = overtaking) OR (Conflict type = converging)) & (hdg changeprohibited by traffic) & (2 a/c level) & ((a/c do not have similar speeds) OR (<2 a/c committed)): 8.2.1 of Function 8.2 -Change FL to resolve conflict (1 a/c) & 8.2.1 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & ((Conflict type = overtaking) OR (Conflict type = converging)) & (hdg changeprohibited by traffic) & (2 a/c level) & (a/c have similar speeds) & (2 a/c committed): 8.3.1 of Function 8.3 -Restrict/change speed to resolve conflictIf (CA not initiated) & (0 a/c calling in) & ((Conflict type = overtaking) OR (Conflict type = converging) OR (Conflict type= head-on)) & (hdg change not prohibited by traffic): 8.4.1 of Function 8.4 - Put both a/c on hdgs to resolve conflict(2 a/c) & 8.4.2 - Edit TDB (a/c 1)If (CA not initiated) & (0 a/c calling in) & (hdg change prohibited by traffic) & (1 a/c level): 8.5.1 of Function 8.5 - Stopclimb / descent of a/c to resolve conflict (2 a/c) & 8.5.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (hdg change prohibited by traffic) & (0 a/c level): 8.6.1 of Function 8.6 - Stopclimb / descent of both a/c to resolve conflict & 8.6.2 - Edit TDB (a/c 1)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

5

5.1

5.1.1

Gather information


Formulate plan by self (Short term)Phase



n/aEffect


Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Text Symbology

Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

5

5.1

5.1.2

Gather information





n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

5

5.2

5.2.1






n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD

Read TDBs

Review mental model


Inspect/Check

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

5

5.2

5.2.2






n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

6

6.1

6.1.1

Gather information


Formulate plan with Planner (Long term)Phase



n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD


Inspect/Check

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

6

6.1

6.1.2

Gather information





n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (clutter = high): 11.1.1 - Move TDBsIf (CA not initiated) & (0 a/c calling in) & (clutter = low): 6.1.3 - Gather info on traffic from TDBs

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

6

6.1

6.1.3

Gather information





n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 6.1.4 - Gather info on traffic from tools

Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Text Symbology

Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

6

6.1

6.1.4

Gather information

Gather info on traffic from tools




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 6.1.5 - Discuss options with Planner

Selection Rules

TASK MODEL

V A C POpen tool (e.g. FFP)

Read tool (e.g. FFP) Text Symbology

Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

6

6.1

6.1.5

Gather information

Discuss options with Planner


8.0Predicted duration 6Observed duration


n/aEffect


Selection Rules

TASK MODEL

V A C PTalk to Planner

Listen to Planner Interpret Speech

SpeakBEHAVIOURS



04/02/98 Annex A


Function

Task

6

6.1

6.1.6

Gather information



1.0Predicted duration 1Observed duration


n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

6

6.2

6.2.1






n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD

Read TDBs

Review mental model


Inspect/Check

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

6

6.2

6.2.2






n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

7

7.1

7.1.1

Gather information


Formulate plan by self (Long term)Phase



n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD


Inspect/Check

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

7

7.1

7.1.2

Gather information





n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (clutter = high): 11.1.1 - Move TDBsIf (CA not initiated) & (0 a/c calling in) & (clutter = low): 7.1.3 - Gather info on traffic from TDBs

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

7

7.1

7.1.3

Gather information





n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in): 7.1.4 - Gather info on traffic from tools

Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Text Symbology

Recall/Prepare

BEHAVIOURS



04/02/98 Annex A


Function

Task

7

7.1

7.1.4

Gather information

Gather info on traffic from tools




n/aEffect


Selection Rules

TASK MODEL

V A C POpen tool (e.g. FFP)

Read tool (e.g. FFP) Text Symbology

Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

7

7.1

7.1.5

Gather information





n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

7

7.2

7.2.1






n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD

Read TDBs

Review mental model


Inspect/Check

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

7

7.2

7.2.2






n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

8

8.1

8.1.1

Change Hdg to resolve conflict (1 a/c)

Change Hdg (RT)

Implement conflict resolution planPhase



If (a/c not on hdg at start of task): +1 a/c on hdgEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.1

8.1.2

Change Hdg to resolve conflict (1 a/c)

Edit TDB




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Function -1 =4.2) & (Function -3 =3.6) & (Function -4 interruptible): Task -9If (CA not initiated) & (0 a/c calling in) & (Function -1 =5.2) & (Function -3 =3.6) & (Function -4 interruptible): Task -8If (CA not initiated) & (0 a/c calling in) & ((Function -3 not=3.6) OR (Function -4 not interruptible)): 3.1.1 of Function 3.1- Determine focus for monitoring

Selection Rules

TASK MODEL

V A C PSelect Hdg from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.2

8.2.1

Change FL to resolve conflict (1 a/c)

Change FL (RT)




a/c at new FLEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.2

8.2.2

Change FL to resolve conflict (1 a/c)

Edit TDB




n/aEffect


Selection Rules

TASK MODEL

V A C PSelect FL from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.1

Restrict/change speed to resolve conflict

Request speed info (a/c 1) (RT)




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 8.3.2 - Request speed info (a/c 2) (RT)

Selection Rules

TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.2


Request speed info (a/c 2) (RT)




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 8.3.3 - Restrict/change speed (a/c 2) (RT) & 8.3.4 - Edit TDB (a/c 2)

Selection Rules

TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.3


Restrict/change speed (a/c 2) (RT)




a/c at specified speedEffect

Concurrent with 8.3.4 - Edit TDB (a/c 2)Selection Rules

TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.4


Edit TDB (a/c 2)




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 8.3.5 - Restrict/change speed (a/c 1) (RT) & 8.3.6 - Edit TDB (a/c 1)

Selection Rules

TASK MODEL

V A C PSelect speed from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.5


Restrict/change speed (a/c 1) (RT)




a/c at specified speedEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.3

8.3.6


Edit TDB (a/c 1)




n/aEffect


Selection Rules

TASK MODEL

V A C PSelect speed from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.4

8.4.1

Put both a/c on hdgs to resolve conflict (2 a/c)

Change Hdg (a/c 1) (RT)




If )a/c not on hdg at start of task): +1 a/c on hdgEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.4

8.4.2


Edit TDB (a/c 1)




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 8.4.3 - Change Hdg (a/c 2) (RT) & 8.4.4 - Edit TDB (a/c 2)

Selection Rules

TASK MODEL

V A C PSelect heading from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.4

8.4.3


Change Hdg (a/c 2) (RT)




If (a/c not on hdg at start of task): +1 a/c on hdgEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.4

8.4.4


Edit TDB (a/c 2)




n/aEffect


Selection Rules

TASK MODEL

V A C PSelect heading from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.5

8.5.1

Stop climb / descent of a/c to resolve conflict (1 a/c)

Stop climb / descent (RT)




a/c at new FLEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.5

8.5.2

Stop climb / descent of a/c to resolve conflict (1 a/c)

Edit TDB




n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

8

8.6

8.6.1

Stop climb / descent of both a/c to resolve conflict

Stop climb / descent (a/c 1) (RT)




If (a/c not on hdg at start of task): +1 a/c on hdg & a/c at new FLIf (a/c on hdg at start of task): a/c at new FL

Effect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.6

8.6.2


Edit TDB (a/c 1)




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated): 8.6.3 - Stop climb / descent (a/c 2) (RT) & Edit TDB (a/c 2)

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

8

8.6

8.6.3


Stop climb / descent (a/c 2) (RT)




a/c at new FLEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

8

8.6

8.6.4


Edit TDB (a/c 2)




n/aEffect


Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

9

9.1

9.1.1

Change FL to XFL

Change FL (RT)

Issue routine instructionsPhase



+1 a/c at XFLEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

9

9.1

9.1.2

Change FL to XFL

Edit TDB




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 1.3) OR ((Function -4 = 1.3) & (Function -2 = 11.1))) & (WL =High): 3.4.1 of Function 3.4 - Identify possible conflicts (Short term)If (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 1.3) OR ((Function -4 = 1.3) & (Function -2 = 11.1))) & (WL =Low): 3.5.1 of Function 3.5 - Identify possible conflicts (Short & long term)If (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 3.2) OR ((Function -4 = 3.2) & (Function -2 = 11.1))) : 3.2.2 ofFunction 3.2 - Determine if any a/c require releasing (transfer)If (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 3.3) OR ((Function -4 = 3.3) & (Function -2 = 11.1))): 3.3.3 -Gather info on Hdg

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

9

9.2

9.2.1

Change FL to interim FL

Change FL (RT)




a/c at new FLEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

9

9.2

9.2.2

Change FL to interim FL

Edit TDB




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 1.3) OR ((Function -4 = 1.3) & (Function -2 = 11.1))) & (WL =High): 3.4.1 of Function 3.4 - Identify possible conflicts (Short term)If (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 1.3) OR ((Function -4 = 1.3) & (Function -2 = 11.1))) & (WL =Low): 3.5.1 of Function 3.5 - Identify possible conflicts (Short & long term)If (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 3.2) OR ((Function -4 = 3.2) & (Function -2 = 11.1))) & (a/c noton hdg): 12.1.1 - Talk with adjacent sectorIf (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 3.2) OR ((Function -4 = 3.2) & (Function -2 = 11.1))) & (a/c onhdg): 10.2.3 of Function 10.2 - Assess implications of putting a/c on own navigationIf (CA not initiated) & (0 a/c calling in) & ((Function - 2 = 3.3) OR ((Function -4 = 3.3) & (Function -2 = 11.1))): 3.3.3 -Gather info on Hdg

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

9

9.3

9.3.1

Put a/c own navig

Put a/c on own navig (RT)




-1 a/c on hdgEffect


TASK MODEL

V A C PActivate RT

Talk to a/c


Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


Function

Task

9

9.3

9.3.2

Put a/c own navig

Edit TDB




n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & ((Function -2 = 3.2) OR ((Function -4 =3.2) & (Function -2 =11.1))) & (AFL =XFL): 3.2.2 of Function 3.2 - Determine if any a/c require releasing (transfer)If (CA not initiated) & (0 a/c calling in) & ((Function -2 = 3.2) OR ((Function -4 =3.2) & (Function -2 =11.1))) & (AFL not=XFL): 12.1.1 - Talk with adjacent sectorIf (CA not initiated) & (0 a/c calling in) & ((Function -2 = 3.3) OR ((Function -4 =3.3) & (Function -2 =11.1))) & ((no. a/con hdg at start of cycle > no. times Task 3.3.1 performed in cycle) OR (no. a/c AFL not= XFL at start of cycle > no.times Task 3.3.1 performed in cycle)): 3.3.1 of Function 3.3 - Assess individual a/c requirementsIf (CA not initiated) & (0 a/c calling in) & ((Function -2 = 3.3) OR ((Function -4 =3.3) & (Function -2 =11.1))) & ((no. a/con hdg at start of cycle) <= (no. times Task 3.3.1 performed in cycle)) & ((no. a/c AFL not= XFL at start of cycle) <=(no. times Task 3.3.1 performed in cycle)): 3.1.1 of Function 3.1 - Determine focus for monitoring

Selection Rules

TASK MODEL

V A C PSelect hdg from TDB Reach/SwitchBEHAVIOURS



04/02/98 Annex A


Function

Task

10

10.1

10.1.1

Assess implications of changing FL


Assess implications of changing a/c parameterPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in):10.1.2 - Determine requirement to housekeep

Selection Rules

TASK MODEL

V A C PLook at PVD


Inspect/Check

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

10

10.1

10.1.2






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (clutter = high): 11.1.1 - Move TDBsIf (CA not initiated) & (0 a/c calling in) & (clutter = low): 10.1.3 - Gather info on traffic

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

10

10.1

10.1.3






n/aEffect


Selection Rules

TASK MODEL

V A C PDetect other a/c at requested & interim FLs

Read TDBs for above a/c

Review mental model


Detect

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

10

10.1

10.1.4






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Conf at req FL =0) & (Conf at interim FLs =0): 9.1.1 of Function 9.1 -Change FL to XFL & 9.1.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (Conf at req FL >0) & (Conf at interim FLs = 0): 9.2.1 of Function 9.2 -Change FL to interim FL & 9.2.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (Conf at interim FLs > 0) & ((Function - 1 = 1.3) OR ((Function - 3 = 1.3) &(Function -1 =11.1))) & (WL = High): 3.4.1 of Function 3.4 - Identify possible conflicts (Short term)If (CA not initiated) & (0 a/c calling in) & (Conf at interim FLs > 0) & ((Function - 1 = 1.3) OR ((Function - 3 = 1.3) &(Function -1 =11.1))) & (WL = Low): 3.5.1 of Function 3.5 - Identify possible conflicts (Short & long term)If (CA not initiated) & (0 a/c calling in) & (Conf at interim FLs > 0) & ((Function - 1 = 3.2) OR ((Function -3 = 3.2) &(Function -1 =11.1))) & (a/c not on hdg): 12.1.1 - Talk with adjacent sectorIf (CA not initiated) & (0 a/c calling in) & (Conf at interim FLs > 0) & ((Function - 1 = 3.2) OR ((Function -3 = 3.2) &(Function -1 =11.1))) & (a/c on hdg): 10.2.3 of Function 10.2 - Assess implications of putting a/c on ownnavigationIf (CA not initiated) & (0 a/c calling in) & (Conf at interim FLs > 0) & ((Function - 1 = 3.3) OR ((Function -3 = 3.3) &(Function -1 =11.1))): 3.3.3 - Gather info on Hdg

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

10

10.2

10.2.1

Assess implications of putting a/c on own navigation





n/aEffect


Selection Rules

TASK MODEL

V A C PLook at PVD


Inspect/Check

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

10

10.2

10.2.2






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (clutter = high): 11.1.1 - Move TDBsIf (CA not initiated) & (0 a/c calling in) & (clutter = low): 10.2.3 - Gather info on traffic

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

10

10.2

10.2.3






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in):10.2.4 - Determine required action

Selection Rules

TASK MODEL

V A C PRead TDBs

Review mental model

Determine if conflict has been averted

Text Symbology

Recall/Prepare

Judge

BEHAVIOURS



04/02/98 Annex A


Function

Task

10

10.2

10.2.4






n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Conflict has been averted): 9.3.1 Put a/c on own navig (RT) & 9.3.2 - EditTDBIf (CA not initiated) & (0 a/c calling in) & (Conflict has not been averted) & ((Function -1 =3.2) OR ((Function -3 =3.2) &(Function -1 = 11.1)) OR (Function -1 = 10.1)): 12.1.1 - Talk with adjacent sectorIf (CA not initiated) & (0 a/c calling in) & (Conflict has not been averted) & ((Function -1 = 3.3) OR ((Function -3 = 3.3)& (Function -1 =11.1))) & ((no. a/c on hdg at start of cycle > no. times Task 3.3.1 performed in cycle) OR (no. a/c AFLnot= XFL at start of cycle > no. times Task 3.3.1 performed in cycle)): 3.3.1 of Function 3.3 - Assess individual a/crequirementsIf (CA not initiated) & (0 a/c calling in) & (Conflict has not been averted) & ((Function -1 = 3.3) OR ((Function -3 = 3.3)& (Function -1 =11.1))) & ((no. a/c on hdg at start of cycle) <= (no. times Task 3.3.1 performed in cycle)) & ((no. a/cAFL not= XFL at start of cycle) <= (no. times Task 3.3.1 performed in cycle)): 3.1.1 of Function 3.1 - Determine focusfor monitoring

Selection Rules

TASK MODEL




04/02/98 Annex A


Function

Task

11

11.1

11.1.1

Tidy TDBs

Move TDBs

HousekeepingPhase



Reduced degree of clutterEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 3.1): 3.1.3 - Review air pictureIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 6.1): 6.1.3 - Gather info on traffic from TDBsIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 7.1): 7.1.3 - Gather info on traffic from TDBsIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 10.1): 10.1.3 - Gather info on trafficIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 10.2): 10.2.3 - Gather info on traffic

Selection Rules

TASK MODEL

V A C PMove TDBs Adjust/MoveBEHAVIOURS



04/02/98 Annex A


Function

Task

12

12.1

12.1.1

Liaise with adjacent sector

Talk with adjacent sector

Liaise with adjacent sectorPhase



n/aEffect

If (CA initiated): 3.6.1 - Gather info on conflicting a/cIf (CA not initiated) & (a/c calling in): 1.1.1 - Listen to a/c calling inIf (CA not initiated) & (0 a/c calling in) & (Function - 1 = 1.2): 1.2.2 - Edit TDBIf (CA not initiated) & (0 a/c calling in) & (Function -1 = 3.2): 3.2.2 of Function 3.2 - Determine if any a/c requirereleasing (transfer)If (CA not initiated) & (0 a/c calling in) & ((Function -1 =9.2) OR (Function -1 =10.1) OR (Function -1 =10.2) OR(Function -1 = 9.3)): 2.1.1 - Release a/c (RT) (transfer) & 2.1.2 - Edit TDB

Selection Rules

TASK MODEL

V A C PActivate phone

Talk to next sector

Listen to next sector Interpret Speech

Reach/Switch

Speak

BEHAVIOURS



04/02/98 Annex A


%�� $SSHQGL[�%

(852&21752/

��

�"�#$��%��&�' � (��


$SSHQGL[�% %��

(852&21752/


9DOLGDWLRQ�RI�D�0HWKRGRORJ\�IRU�3UHGLFWLQJ�3HUIRUP

DQFH��:

RUNORDG

$SSHQGL[�%

��%��

(852&21752/

��

Ass

ess

impl

icat

ions

of

chan

ging

FL

-G

athe

r in

fo o

ntr

affi

c

��

Hou

seke

epin

g -

Mov

e T

DB

s

��

Iden

tify

poss

ible

conf

licts

(Sh

ort &

long

term

) -

Gat

her

info

on

traf

fic

��

Iden

tify

poss

ible

conf

licts

(Sh

ort

term

) -

Gat

her

info

on

traf

fic

��

Ass

ess

impl

icat

ions

of c

hang

ing

FL-

Ass

ess

degr

ee o

fcl

utte

r

��

Iden

tify

poss

ible

conf

licts

(Sh

ort

term

) -

Det

erm

ine

requ

ired

act

ion

��

Ass

ess

new

a/c

-D

eter

min

e re

quir

edac

tion

��

Form

ulat

e pl

an b

yse

lf (

Shor

t ter

m)-

Gat

her

info

on

traf

fic

from

TD

Bs

If $)/

not

=;)/

AFL

& X

FL in

put

man

ually

into

scen

ario

If ($)/

= ;)/

)&

(:/

=lo

w)

If ($)/

= ;)/

)&

(:/

=hi

gh)

AFL

& X

FL in

put

man

ually

into

scen

ario

; WL

cal

cula

ted

from

Qe

ratin

gs in

tas

k in

fo

If FOXWWHU

= h

igh

Deg

ree

of c

lutt

erin

put

man

ually

into

scen

ario

If FOXWWHU

= lo

w

Deg

ree

of c

lutt

er in

put

man

ually

into

sce

nari

o

If FRQ

IOLFW =

0

Con

flict

info

inpu

tm

anua

lly in

to s

cena

rio

If (FRQIOLFW

>0)

&(3&�DYDLODE

OH)

If (FRQIOLFW

>0)

& (3&

QRW �DYDLODEOH)

Con

flict

info

& P

C a

vaila

bilit

yin

put

man

ually

into

sce

nari

o

��

Ass

ess

impl

icat

ions

of c

hang

ing

FL-

Det

erm

ine

requ

irem

ent t

oho

usek

eep

��

Iden

tify

poss

ible

conf

licts

(Sh

ort &

long

term

) -

Det

erm

ine

requ

ired

actio

n

��

Form

ulat

e pl

anw

ith P

lann

er(S

hort

term

) -

Gat

her

info

on

traf

fic

from

TD

Bs

��

Mon

itori

ng-

Ass

ess

degr

eeof

clu

tter


&�� $SSHQGL[�&

(852&21752/

��

��)��&�)��*(� �� +�,�-'��'�)


$SSHQGL[�& &��

(852&21752/




(852&21752/

7DVN 6WDUW 3UHGLFWHG'XUDWLRQ

(QG :RUNORDG

3.1.1 35:00 00:01 35:01 Marginal3.1.2 35:01 00:01 35:02 Marginal11.1.1 35:02 00:02 35:04 Acceptable3.1.3 35:04 00:02 35:06 Marginal1.1.1 35:06 00:03 35:09 Acceptable1.1.2 35:09 00:02 35:11 Marginal1.1.3 35:11 00:01 35:12 Unacceptable/ Marginal1.2.1 35:12 00:02 35:14 Marginal1.2.2 35:12 00:01 35:13 Marginal1.3.1 35:14 00:01 35:15 Marginal1.3.2 35:15 00:01 35:16 Unacceptable/ Marginal10.1.1 35:16 00:01 35:17 Marginal10.1.2 35:17 00:01 35:18 Marginal11.1.1 35:18 00:02 35:20 Acceptable10.1.3 35:20 00:03 35:23 Unacceptable/ Marginal10.1.4 35:23 00:01 35:24 Unacceptable3.4.1 35:24 00:03 35:27 Marginal3.4.2 35:27 00:01 35:28 Marginal4.1.1 35:28 00:03 35:31 Acceptable/ Marginal4.1.2 35:31 00:03 35:34 Unacceptable/ Marginal4.1.3 35:34 00:01 35:35 Unacceptable/ Marginal4.2.1 35:35 00:04 35:39 Unacceptable/ Marginal4.2.2 35:39 00:01 35:40 Unacceptable8.1.1 35:40 00:07 35:47 Unacceptable/ Marginal8.1.2 35:40 00:01 35:41 Unacceptable/ Marginal3.1.1 35:47 00:01 35:48 Marginal3.1.2. 35:48 00:01 35:49 Marginal11.1.1 35:49 00:02 35:51 Acceptable3.1.3 35:51 00:02 35:53 Marginal3.1.4 35:53 00:01 35:54 Marginal3.3.1 35:54 00:01 35:55 Unacceptable/ Marginal3.3.2 35:55 00:01 35:56 Unacceptable/ Marginal3.3.3 35:56 00:01 35:57 Unacceptable/ Marginal3.3.4 35:57 00:01 35:58 Unacceptable/ Marginal3.3.1 35:58 00:01 35:59 Unacceptable/ Marginal3.3.2 35:59 00:01 36:00 Unacceptable/ Marginal3.3.3 36:00 00:01 36:01 Unacceptable/ Marginal3.3.4 36:01 00:01 36:02 Unacceptable/ Marginal3.3.1 36:02 00:01 36:03 Unacceptable/ Marginal3.3.2 36:03 00:01 36:04 Unacceptable/ Marginal3.3.3 36:04 00:01 36:05 Unacceptable/ Marginal3.3.4 36:05 00:01 36:06 Unacceptable/ Marginal3.3.1 36:06 00:01 36:07 Unacceptable/ Marginal3.3.2 36:07 00:01 36:08 Unacceptable/ Marginal3.3.3 36:08 00:01 36:09 Unacceptable/ Marginal3.3.4 36:09 00:01 36:10 Unacceptable/ Marginal3.3.1 36:10 00:01 36:11 Unacceptable/ Marginal3.3.2 36:11 00:01 36:12 Unacceptable/ Marginal3.3.3 36:12 00:01 36:13 Unacceptable/ Marginal



(852&21752/


(QG :RUNORDG

3.3.4 36:13 00:01 36:14 Unacceptable/ Marginal3.3.1 36:14 00:01 36:15 Unacceptable/ Marginal3.3.2 36:15 00:01 36:16 Unacceptable/ Marginal3.3.3 36:16 00:01 36:17 Unacceptable/ Marginal3.3.4 36:17 00:01 36:18 Unacceptable/ Marginal3.1.1 36:18 00:01 36:19 Marginal3.1.2 36:19 00:01 36:20 Marginal3.1.3 36:20 00:02 36:22 Marginal3.1.4 36:22 00:01 36:23 Marginal3.5.1 36:23 00:04 36:27 Marginal1.1.1 36:27 00:03 36:30 Acceptable1.1.2 36:30 00:02 36:32 Marginal1.1.3 36:32 00:01 36:33 Unacceptable/ Marginal1.2.1 36:33 00:02 36:35 Marginal1.2.2 36:33 00:01 36:34 Marginal1.3.1 36:35 00:01 36:36 Marginal1.3.2 36:36 00:01 36:37 Unacceptable/ Marginal3.4.1 36:37 00:03 36:40 Marginal3.4.2 36:40 00:01 36:41 Marginal4.1.1 36:41 00:03 36:44 Acceptable/ Marginal4.1.2 36:44 00:03 36:47 Unacceptable/ Marginal4.1.3 36:47 00:01 36:48 Unacceptable/ Marginal4.2.1 36:48 00:04 36:52 Unacceptable/ Marginal4.2.2 36:52 00:01 36:53 Unacceptable8.1.1 36:53 00:07 37:00 Unacceptable/ Marginal8.1.2 36:53 00:01 36:54 Unacceptable/ Marginal3.1.1 37:00 00:01 37:01 Marginal3.1.2 37:01 00:01 37:02 Marginal3.1.3 37:02 00:02 37:04 Marginal3.5.1 37:04 00:10 37:14 Marginal3.5.2 37:14 00:01 37:15 Marginal6.1.1 37:15 00:01 37:16 Marginal6.1.2 37:16 00:01 37:17 Marginal6.1.3 37:17 00:10 37:27 Acceptable/ Marginal6.1.4 37:27 00:05 37:32 Acceptable/ Marginal6.1.5 37:32 00:08 37:40 Unacceptable/ Marginal6.1.6 37:40 00:01 37:41 Unacceptable/ Marginal6.2.1 37:41 00:07 37:48 Unacceptable/ Marginal6.2.2 37:48 00:01 37:49 Unacceptable8.4.1 37:49 00:07 37:56 Unacceptable/ Marginal8.4.2 37:49 00:01 37:50 Unacceptable/ Marginal8.4.3 37:56 00:07 38:03 Unacceptable/ Marginal8.4.4 37:56 00:01 37:57 Unacceptable/ Marginal3.1.1 38:03 00:01 38:04 Marginal3.1.2 38:04 00:01 38:05 Marginal3.1.3 38:05 00:02 38:07 Marginal3.1.4 38:07 00:01 38:08 Marginal3.2.1 38:08 00:03 38:11 Unacceptable/ Marginal3.2.2 38:11 00:01 38:12 Unacceptable2.1.1 38:12 00:09 38:21 Unacceptable/ Marginal



(852&21752/


(QG :RUNORDG

2.1.2 38:12 00:01 38:13 Unacceptable/ Marginal3.1.1 38:21 00:01 38:22 Marginal3.1.2 38:22 00:01 38:23 Marginal3.1.3 38:23 00:02 38:25 Marginal3.1.4 38:25 00:01 38:26 Marginal3.3.1 38:26 00:01 38:27 Unacceptable/ Marginal3.3.2 38:27 00:01 38:28 Unacceptable/ Marginal3.3.3 38:28 00:01 38:29 Unacceptable/ Marginal3.3.4 38:29 00:01 38:30 Unacceptable/ Marginal3.3.1 38:30 00:01 38:31 Unacceptable/ Marginal3.3.2 38:31 00:01 38:32 Unacceptable/ Marginal3.3.3 38:32 00:01 38:33 Unacceptable/ Marginal3.3.4 38:33 00:01 38:34 Unacceptable/ Marginal3.3.1 38:34 00:01 38:35 Unacceptable/ Marginal3.3.2 38:35 00:01 38:36 Unacceptable/ Marginal3.3.3 38:36 00:01 38:37 Unacceptable/ Marginal3.3.4 38:37 00:01 38:38 Unacceptable/ Marginal10.2.1 38:38 00:01 38:39 Marginal10.2.2 38:39 00:01 38:40 Marginal10.2.3 38:40 00:02 38:42 Marginal10.2.4 38:42 00:01 38:43 Marginal9.3.1 38:43 00:07 38:50 Unacceptable/ Marginal9.3.2 38:43 00:01 38:44 Unacceptable/ Marginal3.3.1 38:50 00:01 38:51 Unacceptable/ Marginal1.1.1 38:51 00:03 38:54 Acceptable1.1.2 38:51 00:02 38:53 Marginal1.1.3 38:54 00:01 38:55 Unacceptable/ Marginal1.2.1 38:55 00:02 38:57 Marginal1.2.2 38:57 00:01 38:58 Marginal1.3.1 38:58 00:01 38:59 Marginal1.3.2 38:59 00:01 39:00 Unacceptable/ Marginal10.1.1 39:00 00:01 39:01 Marginal10.1.2 39:01 00:01 39:02 Marginal10.1.3 39:02 00:03 39:05 Unacceptable/ Marginal10.1.4 39:05 00:01 39:06 Unacceptable3.4.1 39:06 00:03 39:09 Marginal3.4.2 39:09 00:01 39:10 Marginal4.1.1 39:10 00:03 39:13 Acceptable/ Marginal4.1.2 39:13 00:03 39:16 Unacceptable/ Marginal4.1.3 39:16 00:01 39:17 Unacceptable/ Marginal4.2.1 39:17 00:04 39:21 Unacceptable/ Marginal4.2.2 39:21 00:01 39:22 Unacceptable8.4.1 39:22 00:07 39:29 Unacceptable/ Marginal8.4.2 39:22 00:01 39:23 Unacceptable/ Marginal8.4.3 39:29 00:07 39:36 Unacceptable/ Marginal8.4.4 39:29 00:01 39:30 Unacceptable/ Marginal3.1.1 39:36 00:01 39:37 Marginal3.1.2 39:37 00:01 39:38 Marginal3.1.3 39:38 00:02 39:40 Marginal3.1.4 39:40 00:01 39:41 Marginal



(852&21752/


(QG :RUNORDG

3.5.1 39:41 00:10 39:51 Marginal3.5.2 39:51 00:01 39:52 Marginal3.1.1 39:52 00:01 39:53 Marginal3.1.2 39:53 00:01 39:54 Marginal3.1.3 39:54 00:02 39:56 Marginal3.1.4 39:56 00:01 39:57 Marginal3.3.1 39:57 00:01 39:58 Unacceptable/ Marginal3.3.2 39:58 00:01 39:59 Unacceptable/ Marginal3.3.3 39:59 00:01 40:00 Unacceptable/ Marginal3.3.4 40:00 00:01 40:01 Unacceptable/ Marginal3.3.1 40:01 00:01 40:02 Unacceptable/ Marginal3.3.2 40:02 00:01 40:03 Unacceptable/ Marginal3.3.3 40:03 00:01 40:04 Unacceptable/ Marginal3.3.4 40:04 00:01 40:05 Unacceptable/ Marginal3.3.1 40:05 00:01 40:06 Unacceptable/ Marginal3.3.2 40:06 00:01 40:07 Unacceptable/ Marginal3.3.3 40:07 00:01 40:08 Unacceptable/ Marginal3.3.4 40:08 00:01 40:09 Unacceptable/ Marginal3.3.1 40:09 00:01 40:10 Unacceptable/ Marginal3.3.2 40:10 00:01 40:11 Unacceptable/ Marginal3.3.3 40:11 00:01 40:12 Unacceptable/ Marginal3.3.4 40:12 00:01 40:13 Unacceptable/ Marginal3.3.1 40:13 00:01 40:14 Unacceptable/ Marginal3.3.2 40:14 00:01 40:15 Unacceptable/ Marginal3.3.3 40:15 00:01 40:16 Unacceptable/ Marginal1.1.1 40:16 00:03 40:19 Acceptable1.1.2 40:19 00:02 40:21 Marginal1.1.3 40:21 00:01 40:22 Unacceptable/ Marginal1.2.1 40:22 00:02 40:24 Marginal1.2.2 40:22 00:01 40:23 Marginal1.3.1 40:24 00:01 40:25 Marginal1.3.2 40:25 00:01 40:26 Unacceptable/ Marginal3.4.1 40:26 00:03 40:29 Marginal3.4.2 40:29 00:01 40:30 Marginal3.1.1 40:30 00:01 40:31 Marginal3.1.2 40:31 00:01 40:32 Marginal3.1.3 40:32 00:02 40:34 Marginal3.1.4 40:34 00:01 40:35 Marginal3.2.1 40:35 00:03 40:38 Unacceptable/ Marginal3.2.2 40:38 00:01 40:39 Unacceptable2.1.1 40:39 00:09 40:48 Unacceptable/ Marginal2.1.2 40:39 00:01 40:40 Unacceptable/ Marginal3.1.1 40:48 00:01 40:49 Marginal3.1.2 40:49 00:01 40:50 Marginal11.1.1 40:50 00:02 40:52 Acceptable3.1.3 40:52 00:02 40:54 Marginal3.1.4 40:54 00:01 40:55 Marginal3.5.1 40:55 00:10 41:05 Marginal3.5.2 41:05 00:01 41:06 Marginal6.1.1 41:06 00:01 41:07 Marginal



(852&21752/


(QG :RUNORDG

6.1.2 41:07 00:01 41:08 Marginal11.1.1 41:08 00:02 41:10 Acceptable6.1.3 41:10 00:07 41:17 Acceptable/ Marginal1.1.1 41:17 00:03 41:20 Acceptable1.1.2 41:20 00:02 41:22 Marginal1.1.3 41:22 00:01 41:23 Unacceptable/ Marginal1.2.1 41:23 00:02 41:25 Marginal1.2.2 41:23 00:01 41:24 Marginal1.3.1 41:25 00:01 41:26 Marginal1.3.2 41:26 00:01 41:27 Unacceptable/ Marginal10.1.1 41:27 00:01 41:28 Marginal10.1.2 41:28 00:01 41:29 Marginal10.1.3 41:29 00:03 41:32 Unacceptable/ Marginal10.1.4 41:32 00:01 41:33 Unacceptable9.1.1 41:33 00:07 41:40 Unacceptable/ Marginal9.1.2 41:33 00:01 41:34 Unacceptable/ Marginal3.4.1 41:40 00:03 41:43 Marginal3.4.2 41:43 00:01 41:44 Marginal4.1.1 41:44 00:03 41:47 Acceptable/ Marginal4.1.2 41:47 00:03 41:50 Unacceptable/ Marginal4.1.3 41:50 00:01 41:51 Unacceptable/ Marginal4.2.1 41:51 00:04 41:55 Unacceptable/ Marginal4.2.2 41:55 00:01 41:56 Unacceptable8.1.1 41:56 00:07 42:03 Unacceptable/ Marginal8.1.2 41:56 00:01 41:57 Unacceptable/ Marginal3.1.1 42:03 00:01 42:04 Marginal3.1.2 42:04 00:01 42:05 Marginal3.1.3 42:05 00:02 42:07 Marginal3.1.4 42:07 00:01 42:08 Marginal3.2.1 42:08 00:03 42:11 Unacceptable/ Marginal1.1.1 42:11 00:03 42:14 Acceptable1.1.2 42:14 00:02 42:16 Marginal1.1.3 42:16 00:01 42:17 Unacceptable/ Marginal1.2.1 42:17 00:02 42:19 Marginal1.2.2 42:17 00:01 42:18 Marginal1.3.1 42:19 00:01 42:20 Marginal1.3.2 42:20 00:01 42:21 Unacceptable/ Marginal3.4.1 42:21 00:03 42:24 Marginal3.4.2 42:24 00:01 42:25 Marginal4.1.1 42:25 00:02 42:27 Acceptable/ Marginal3.6.1 42:27 00:02 42:29 Marginal3.6.2 42:29 00:01 42:30 Marginal4.1.1 42:30 00:03 42:33 Acceptable/ Marginal4.1.2 42:33 00:03 42:36 Unacceptable/ Marginal4.1.3 42:36 00:01 42:37 Unacceptable/ Marginal4.2.1 42:37 00:04 42:41 Unacceptable/ Marginal4.2.2 42:41 00:01 42:42 Unacceptable8.1.1 42:42 00:07 42:49 Unacceptable/ Marginal8.1.2 42:42 00:01 42:43 Unacceptable/ Marginal3.1.1 42:49 00:01 42:50 Marginal



(852&21752/


(QG :RUNORDG

3.1.2 42:50 00:01 42:51 Marginal3.1.3 42:51 00:02 42:53 Marginal3.1.4 42:53 00:01 42:54 Marginal3.2.1 42:54 00:03 42:57 Unacceptable/ Marginal3.2.2 42:57 00:01 42:58 Unacceptable2.1.1 42:58 00:09 43:07 Unacceptable/ Marginal2.1.2 42:58 00:01 42:59 Unacceptable/ Marginal3.1.1 43:07 00:01 43:08 Marginal3.1.2 43:08 00:01 43:09 Marginal3.1.3 43:09 00:02 43:11 Marginal3.1.4 43:11 00:01 43:12 Marginal3.3.1 43:12 00:01 43:13 Unacceptable/ Marginal3.3.2 43:13 00:01 43:14 Unacceptable/ Marginal3.3.3 43:14 00:01 43:15 Unacceptable/ Marginal3.3.4 43:15 00:01 43:16 Unacceptable/ Marginal3.3.1 43:16 00:01 43:17 Unacceptable/ Marginal3.3.2 43:17 00:01 43:18 Unacceptable/ Marginal3.3.3 43:18 00:01 43:19 Unacceptable/ Marginal3.3.4 43:19 00:01 43:20 Unacceptable/ Marginal3.3.1 43:20 00:01 43:21 Unacceptable/ Marginal3.3.2 43:21 00:01 43:22 Unacceptable/ Marginal3.3.3 43:22 00:01 43:23 Unacceptable/ Marginal3.3.4 43:23 00:01 43:24 Unacceptable/ Marginal3.3.1 43:24 00:01 43:25 Unacceptable/ Marginal3.3.2 43:25 00:01 43:26 Unacceptable/ Marginal3.3.3 43:26 00:01 43:27 Unacceptable/ Marginal3.3.4 43:27 00:01 43:28 Unacceptable/ Marginal3.3.1 43:28 00:01 43:29 Unacceptable/ Marginal3.3.2 43:29 00:01 43:30 Unacceptable/ Marginal3.3.3 43:30 00:01 43:31 Unacceptable/ Marginal3.3.4 43:31 00:01 43:32 Unacceptable/ Marginal10.2.1 43:32 00:01 43:33 Marginal10.2.2 43:33 00:01 43:34 Marginal10.2.3 43:34 00:02 43:36 Marginal10.2.4 43:36 00:01 43:37 Marginal9.3.1 43:37 00:07 43:44 Unacceptable/ Marginal9.3.2 43:37 00:01 43:38 Unacceptable/ Marginal3.3.1 43:44 00:01 43:45 Unacceptable/ Marginal3.3.2 43:45 00:01 43:46 Unacceptable/ Marginal3.3.3 43:46 00:01 43:47 Unacceptable/ Marginal3.3.4 43:47 00:01 43:48 Unacceptable/ Marginal3.3.1 43:48 00:01 43:49 Unacceptable/ Marginal3.3.2 43:49 00:01 43:50 Unacceptable/ Marginal10.1.1 43:50 00:01 43:51 Marginal10.1.2 43:51 00:01 43:52 Marginal10.1.3 43:52 00:03 43:55 Unacceptable/ Marginal10.1.4 43:55 00:01 43:56 Unacceptable9.1.1 43:56 00:07 44:03 Unacceptable/ Marginal9.1.2 43:56 00:01 43:57 Unacceptable/ Marginal3.3.3 44:03 00:01 44:04 Unacceptable/ Marginal



(852&21752/


(QG :RUNORDG

3.3.4 44:04 00:01 44:05 Unacceptable/ Marginal10.2.1 44:05 00:01 44:06 Marginal10.2.2 44:06 00:01 44:07 Marginal10.2.3 44:07 00:02 44:09 Marginal10.2.4 44:09 00:01 44:10 Marginal9.3.1 44:10 00:07 44:17 Unacceptable/ Marginal9.3.2 44:10 00:01 44:11 Unacceptable/ Marginal3.3.1 44:17 00:01 44:18 Unacceptable/ Marginal3.3.2 44:18 00:01 44:19 Unacceptable/ Marginal10.1.1 44:19 00:01 44:20 Marginal10.1.2 44:20 00:01 44:21 Marginal10.1.3 44:21 00:03 44:24 Unacceptable/ Marginal10.1.4 44:24 00:01 44:25 Unacceptable3.3.3 44:25 00:01 44:26 Unacceptable/ Marginal3.3.4 44:26 00:01 44:27 Unacceptable/ Marginal10.2.1 44:27 00:01 44:28 Marginal10.2.2 44:28 00:01 44:29 Marginal10.2.3 44:29 00:02 44:31 Marginal10.2.4 44:31 00:01 44:32 Marginal9.3.1 44:32 00:07 44:39 Unacceptable/ Marginal9.3.2 44:32 00:01 44:33 Unacceptable/ Marginal3.1.1 44:39 00:01 44:40 Marginal3.1.2 44:40 00:01 44:41 Marginal3.1.3 44:41 00:01 44:42 Marginal3.1.4 44:42 00:01 44:43 Marginal3.2.1 44:43 00:03 44:46 Unacceptable/ Marginal3.2.2 44:46 00:01 44:47 Unacceptable2.1.1 44:47 00:09 44:56 Unacceptable/ Marginal2.1.2 44:47 00:01 44:48 Unacceptable/ Marginal3.1.1 44:56 00:01 44:57 Marginal3.1.2 44:57 00:01 44:58 Marginal11.1.1 44:58 00:02 45:00 Acceptable



(852&21752/



'�� $SSHQGL[�'

(852&21752/

��

��%'�#� ��')�� +�� +��&��


$SSHQGL[�' '�2

(852&21752/




(852&21752/

The performance modelling capability of ATLAS utilises a comprehensive set of performancetime prediction algorithms which have been drawn form the engineering psychology literature.These can be applied to derive predictions for task performance time for the fast, median andslow points of the likely population distribution for performance times.

The algorithms are for the most part based on accepted models of human performance. Forexample decision making tasks are typically defined using derivative forms of Hickís Law(Reference 4), whereas movement times are estimated using Fitts’ Law (References 5 & 6). Inaddition, a more general purpose description of human information processing performance isthe model human information processor (see�Reference 7). These three key elements ofATLAS’s performance modelling capability are described below.

�� +LFN¶V�/DZ

Hick’s Law is a means of calculating choice reaction time in situations where complex data areinvolved. Performance time for a decision is given by:

7LPH , +F

=where + is a measure of the information involved in the decision and is given by:

+ /RJ Q= +2 1( ) for n choice alternatives with equal probabilities for selection,and ,

F is the cognitive iteration time which has a Median [Fast-Slow] range of 92 [150~157]

msecs.

Where the n alternatives have different probabilities of selection H is given by:

+ 3/RJ 3L L

L

Q

= +∑ 2 1 1( / )

where 3 is the probability of option L.

�� )LWWV¶�/DZ

Fitts’ law is a means of estimating movement time as a function of distance and accuracyrequirements (i.e. the reach distance to a control and the size of the control). Movement time isgiven by:

0RYHPHQW7LPH , /RJ ' 6P

= +2 0 5( / . )where ,

P is the movement control iteration time and has a Median[Fast-Slow] range of

100[70~120] msecs,D is the distance through which the hand must move to the switch, and S is the diameter of theswitch.

�� 0RGHO�+XPDQ�,QIRUPDWLRQ�3URFHVVRU

The model human information processor describes a cognitive system comprising separatememories and sub-processors. The memories utilise specific data encoding techniques andthey have defined capacities and information (memory) decay rates and recall performancecharacteristics.

The sub-processors each have a defined cycle time which is the time it takes to process one unitof information. These cycle times are given as a triangular distribution of the fastest time,


$SSHQGL[�' '�4

(852&21752/

median time and slowest time. The constants given by the model human information processorwhich can be used for performance time prediction for a more general range of behaviours aregiven below.

6XE�SURFHVVRU�(OHPHQW 6\PERO )DVWWLPH

�PVHFV�

0HGLDQ7LPH�PVHFV�

6ORZ�7LPH�PVHFV�

Perceptual Processor 7S

50 100 200

Cognitive Processor 7 25 70 170

Motor Processor 7P

30 70 100

Eye movement (P

70 230 700

By combining these (and other) models it is possible to derive a complete set of equations foruse in predicting a wide range of human behaviour performance times. These equations aregiven below.

9LVXDO�)XQFWLRQV)XQFWLRQ $OJRULWKP 1RWHV ,PSOHPHQWDWLRQ

LQ�$7/$6

9'HWHFWRegister onset ofvisual stimulus.

TVde = Em + Tp + TcDetect

95HDGRead text orsymbols.

TVr = N[Em + Tp + 2Tc ] N is the number of symbolsor words.

Text Symbology

96FDQContinuousserial inspectionwith multiplefixations.

TVs = P[Em + Tp + 2Tc + Tm ] P is the number of angularscan fixations or the numberof 5 degree intervals withinthe field to be scanned. The5 degree value is based onthe visual span of attentionwhich is nominally 5degrees.

Search

9,QVSHFWDiscreteinspections of astatic location ordisplay.

TVi = I[Em + Tp + 2Tc ] I is the number ofinspections to be performed.

Inspect/ Check

9'LVFULPLQDWHDetect adifferencebetween twovisual stimuli.

TVdi = S[Em + 2T p + 2Tc ] S is the number of stimulipairs.

Compare Identity

97UDFN�RU9/RFDWHMaintainorientation to amoving or statictarget, withmaximum radialvelocity of1degree persecond.

TVt = R[Em + Tp + Tc + Tm ] R is the number of 1 degreechanges in velocity; for astatic target R will be 1.The 1 degree value is basedon the foveal visual fieldwhich represents maximumacuity.

TraceAlign Track



(852&21752/

$XGLWRU\�)XQFWLRQV)XQFWLRQ $OJRULWKP 1RWHV ,PSOHPHQWDWLRQ

LQ�$7/$6

$'HWHFWDetectoccurrence of asound.

TAde = Tp + TcDetect

$9HULI\Detectoccurrence ofanticipatedsound such asauditoryfeedback.

TAv = Tp + 2TcVerify Feedback

$2ULHQWGeneralorientation orattention to asingle sound.

TAo = Tp + 2Tc + TmLocate

$,QWHUSUHWInterpret themeaning ofsound such asspeech.

TAi = W[Tp + 3Tc ] W is the number of words inthe message.An extra cognitive cycle isneeded to recognise theword, check its meaningand associate it to thecontext of the message.

Interpret Speech

$$WWHQGSelectiveorientation orattention to aspecific sound.

TAa = C[Tp + Tc + Ic log2 (c +1)] C is the number of

alternative sounds, and Ic

is the cognitive iterationtime which has a medianrange of 92[150-157]msecs. This is a variant ofthe Hick’s Law of choicereaction time.

Verify & Locate

$'LVFULPLQDWHDetect auditorydifferencesbetween twosounds.

TAdi = S[2T p + 2Tc ] S is the number of stimulipairs.

Compare

$3DWWHUQInterpretation ofsound patterns,such as in Morsecode.

TAp = D[5Tp + 5Tc ] D is the number of stimulidots or dashes. On averagefour dots or dashes(including the break) areneeded per letter with anaverage of five letters perword.

Analyse Pattern


$SSHQGL[�' '�6

(852&21752/

&RJQLWLYH�)XQFWLRQV)XQFWLRQ $OJRULWKP 1RWHV ,PSOHPHQWDWLRQ

LQ�$7/$6

&6LPSOHSimpleassociation e.g.light = ON.

TCs = Tp + TcSimple Reaction

&5HFRJQLVHSign/symbol/letter recognition.

TCr = T p + 2TcRecognise

&&KRLFHSelection fromalternativeresponses to amessage.

TCc = Tp + NTcN is the number ofalternatives.

Choice Reaction

&(VWLPDWH�RU&5HFDOOEstimation,calculation,conversion orrecall ofinformation.

TCe = TcCalculateRecall/ Prepare

&(YDOXDWH�Evaluation ordecisioninvolvingconsideration ofa singlealternative.

TCh1 = Tp + Tc + I c log2 (2) Ic is the cognitive iteration

time which has a medianrange of 92[150-157]. Thisis a variant of the Hick’sLaw of choice reactiontime.

Decide

&(YDOXDWH�Evaluation ordecisioninvolving anumber ofequally likelyalternatives.

TCh2 = H[Tp + Tc + Ic log2 (H + 1)] H is the number ofalternatives to beconsidered, and

Ic is the cognitive iteration

time which has a medianrange of 92[150-157]. Thisis a variant of the Hick’sLaw of choice reactiontime.

Judge



(852&21752/

3V\FKRPRWRU�)XQFWLRQV)XQFWLRQ $OJRULWKP 1RWHV ,PSOHPHQWDWLRQ

LQ�$7/$6

36SHDN TPs = a + b(N −1) + y(n −1)2 Where N is the number ofwords to be spoken, a is theintercept which is either122.4 or 173.4 msecs for oneand two syllable wordsrespectively, b is the linearcoefficient which is either 92or 180.4 msecs, and y is thequadratic coefficient whichranges from 14.5 [9.5-19.4]msecs per word for medianperformance (see Reference8).

Speak

3$FWLRQA simple reachand switchactivation.

TPa = Tc + Tp + Tm + [Im log2 (D / S + 0.5)] Where Im is the movement

control iteration time whichhas a median range of 100[70-120] msecs, D is thedistance through which thehand must move to theswitch, and S is the diameterof the switch.

Reach/ Switch

30DQLSXODWH�3$GMXVW�RU3&RQWUROReach andmanipulation ofobject; Discreteadjustment of acontrol;Continuousadjustment of acontrol basedon feedback.

TPc = N[Tc + Tp + Tm ] + Im log2 (D / S + 0.5) Where N is the number of

adjustments to be made, Im

is the movement controliteration time which has amedian range of 100 [70-120] msecs,D is the distance throughwhich the hand must move tothe switch, and S is thediameter of the switch.

ManipulateAdjustControl

37\SLQJTyping text ona keyboard.

TPt = Tii

K

∑Where K is the number ofkeystrokes to be performed,and T is the keystrokeexecution time for key strokei; this has a median range of333.2 [158-1154] msecs.

Keying

3.H\LQJKeyingnumbers on akey pad.

TPk = Tii

K

∑Where K is the number ofkeystrokes to be performed,and T is the keystrokeexecution time for key strokei; this has a median range of577 [300-1091] msecs.

Keying

3:ULWHManualproduction ofcharacters.

TPw = Tii

W

∑Where W is the number ofletters to be written, and T isthe writing time for letter i;this has a median range of732 [545-952] msecs.

Write/ Draw


$SSHQGL[�' '�8

(852&21752/



(�� $SSHQGL[�(

(852&21752/

��

� ��!��'&�


$SSHQGL[�( (��

(852&21752/




(852&21752/

0

1

2

3

4

5

6

7

8

9

10

11

1 6

11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86

Sequence Number

Observed

Predicted

)LJXUH��

0

1

2

3

4

5

6

35:0

0

35:3

0

36:0

0

36:3

0

37:0

0

37:3

0

38:0

0

38:3

0

39:0

0

39:3

0

40:0

0

40:3

0

41:0

0

41:3

0

42:0

0

42:3

0

43:0

0

43:3

0

44:0

0

44:3

0

Time

Predicted Workload (Highs & Lows)

Observed workload (based on % time on ATC tasks)

)LJXUH��


$SSHQGL[�( (��

(852&21752/

0

1

2

3

4

5

6

35:0

0

35:3

0

36:0

0

36:3

0

37:0

0

37:3

0

38:0

0

38:3

0

39:0

0

39:3

0

40:0

0

40:3

0

41:0

0

41:3

0

42:0

0

42:3

0

43:0

0

43:3

0

44:0

0

44:3

0

Time

Predicted Workload (Highs & Lows)Observed workload (based on No. RT Transmissions)

)LJXUH��

0

1

2

3

4

5

6

35:0

0

35:3

0

36:0

0

36:3

0

37:0

0

37:3

0

38:0

0

38:3

0

39:0

0

39:3

0

40:0

0

40:3

0

41:0

0

41:3

0

42:0

0

42:3

0

43:0

0

43:3

0

44:0

0

44:3

0

Time

Predicted Workload (Average over 10 second interval)Observed workload (based on % time on ATC tasks)

)LJXUH��



(852&21752/

0

1

2

3

4

5

6

35:0

0

35:3

0

36:0

0

36:3

0

37:0

0

37:3

0

38:0

0

38:3

0

39:0

0

39:3

0

40:0

0

40:3

0

41:0

0

41:3

0

42:0

0

42:3

0

43:0

0

43:3

0

44:0

0

44:3

0

Time

Predicted Workload (Average over 10 second interval)Observed workload (based on No. RT Transmissions)

)LJXUH��

predicting performance and workload - eurocontrol

Documents