guidance material for hp automation support (condensed...

Guidance Material for HP Automation Support (Condensed Version)

Document information

Project title Identification and Integration of Automation Related Good Practices

Project N° 16.05.01

Project Manager ENAV

Deliverable Name

Guidance Material for HP Automation Support (Condensed Version)

Deliverable ID Del 04

Edition 00.01.00

Template version 02.00.01

Task contributors

AENA, AIRBUS, DFS, ENAV, EUROCONTROL, NATMIG, THALES

Please complete the advanced properties of the document

Abstract

This document is a condensed version of the deliverable “Guidance Material for HP Automation Support”. It provides guidance on automation design and evaluation that HF specialists can apply to airborne and ground operational and technical projects involving automation. Guidance is proposed mainly for three HP activities relevant to automation design:

Identifying potential human performance issues that may emerge as a result of the introduction of automation support, and which are considered to be specifically relevant to the SESAR Target Concept of Operations.

Identifying the appropriate level of automation for an existing or targeted system or tool.

Developing principles of automation design.

Project 16.05.01 Edition 00.01.00 Del Error! Unknown document property name. - Guidance Material for HP Automation Support (Condensed Version)

2 of 97

Authoring & Approval

Prepared By

Luca Save (Deep Blue on behalf of ENAV) Task Leader & Task Contributor

Paola Tomasello (Deep Blue on behalf of ENAV) Task Contributor

Beatrice Feuerberg (Egis Avia on behalf of AIRBUS) Task Contributor

Mélanie Morel (Egis Avia on behalf of AIRBUS) Task Contributor

Jean-Philippe Pinheiro (THALES) Task Contributor

Gabriella Paniccia (THALES) Task Contributor

Aline Labreuil (THALES) Task Contributor

Stefan Tenoort (DFS) Task Contributor

Michael Stiso (SINTEF on behalf of NATMIG) Task Contributor

Catherine Chalon Morgan (EUROCONTROL) Task Contributor

Rebeca Llorente Martinez (AENA) Task Contributor

Laura Mateos Buigues (AENA) Task Contributor

Reviewed By

Luca Save (Deep Blue on behalf of ENAV) Task Leader & Task Contributor

Beatrice Feuerberg (Egis Avia on behalf of AIRBUS) Task Contributor

Jean-Philippe Pinheiro (THALES) Task Contributor

Aline Labreuil (THALES) Task Contributor

Stefan Tenoort (DFS) Task Contributor

Michael Stiso (SINTEF on behalf of NATMIG) Task Contributor

Catherine Chalon Morgan (EUROCONTROL) Task Contributor

Rebeca Llorente Martinez (AENA) Task Contributor

Laura Mateos Buigues (AENA) Task Contributor

Plinio Adriano Frasca (ENAV) Project Manager

Approved By

Laura Mateos Buigues (AENA) Project Member 14/02/2013

Florence Reuzeau (AIRBUS) Project Member 14/02/2013

Plinio Adriano Frasca (ENAV) Project Member 14/02/2013

Catherine Chalon Morgan (EUROCONTROL) Project Member 14/02/2013

Stefan Tenoort (DFS) Project Member 14/02/2013

Michael Stiso (NATMIG-NORACON) Project Member 14/02/2013

Jean-Philippe Pinheiro (THALES) Project Member 14/02/2013


3 of 97

Document History

Edition Date Status Author Justification

00.00.01 28/01/2013 Version for partners’ approval

Luca Save, Beatrice Feuerberg

Created based on the full version of the “Final Guidance Material” after AUs feedback and 16.6.5 test application

00.01.00 14/02/2013 Final Luca Save, Beatrice Feuerberg

Approved version for submission


4 of 97

Table of Contents

TABLE OF CONTENTS ..................................................................................................................................... 4

LIST OF TABLES ................................................................................................................................................ 5

LIST OF FIGURES .............................................................................................................................................. 5

EXECUTIVE SUMMARY .................................................................................................................................... 7

1 INTRODUCTION ................................................................................................................................. 8

1.1 THE NEED FOR AUTOMATION .................................................................................................................. 8 1.2 PROBLEMS ASSOCIATED WITH AUTOMATION.......................................................................................... 8 1.3 STRUCTURE OF THE GUIDANCE MATERIAL ............................................................................................. 9 1.4 ACRONYMS ........................................................................................................................................... 10

2 HOW TO UNDERSTAND THIS GUIDANCE MATERIAL .......................................................... 15

2.1 OVERVIEW OF THE MATERIAL ............................................................................................................... 15

3 GUIDANCE ON AUTOMATION AND AUTOMATION ISSUES ............................................... 17

3.1 DETERMINING AUTOMATION ................................................................................................................. 17 3.2 IDENTIFYING HP AUTOMATION ISSUES ................................................................................................ 17

3.2.1 Role changes and task allocation (issues 1 to 7) .................................................................. 17 3.2.2 Working method and task changes (issues 8 to 14) ............................................................. 18 3.2.3 Information presentation in human-machine interaction (issues 15 to 20) ........................ 19 3.2.4 Trust and system reliability (issues 21 to 25) ......................................................................... 19 3.2.5 Communication (issues 26 to 28) ............................................................................................ 20

4 A NEW LEVEL OF AUTOMATION TAXONOMY AND A METHOD TO APPLY IT .............. 21

4.1 LOAT: A NEW LEVEL OF AUTOMATION TAXONOMY .............................................................................. 21 4.1.1 The cognitive functions to be supported by automation ....................................................... 21 4.1.2 Level of automation taxonomy: A set of automation levels for each cognitive function .. 24

4.2 METHOD TO IDENTIFY THE LEVEL OF AUTOMATION AND APPLY THE DESIGN PRINCIPLES ................... 28 4.2.1 Determine the applicable cognitive function(s) supported ................................................... 29 4.2.2 Identify the level of automation ................................................................................................ 30

5 AUTOMATION DESIGN PRINCIPLES ......................................................................................... 31

5.1 DESIGN PRINCIPLES FOR INFORMATION ACQUISITION FUNCTIONS (IAC) ........................................... 37 5.2 DESIGN PRINCIPLES FOR INFORMATION ANALYSIS FUNCTIONS (IAN) ................................................ 48 5.3 DESIGN PRINCIPLES FOR DECISION AND ACTION SELECTION FUNCTIONS (DAS) ............................... 64 5.4 DESIGN PRINCIPLES FOR ACTION IMPLEMENTATION SUPPORT FUNCTIONS (AIS) .............................. 76 5.5 DESIGN PRINCIPLES TRANSVERSAL TO AUTOMATIONS SUPPORTING DIFFERENT COGNITIVE

FUNCTIONS (TRA) ............................................................................................................................... 84

6 REFERENCES .................................................................................................................................. 94


5 of 97

List of tables

Table 1: Examples of Automation Issues on role changes and task allocation .................................... 18 Table 2: Examples of Automation Issues on working method and task changes ................................. 18 Table 3: Examples of Automation Issues on information presentation in HCI ...................................... 19 Table 4: Examples of Automation Issues on trust and system reliability .............................................. 19 Table 5: Examples of Automation Issues on communication ............................................................... 20 Table 6: Cognitive functions and examples of automation in support .................................................. 22 Table 7: Overview of design principles for IAC ..................................................................................... 32 Table 8: Overview of design principles for IAN ..................................................................................... 33 Table 9: Overview of design principles for DAS.................................................................................... 34 Table 10: Overview of design principles for AIS ................................................................................... 35 Table 11: Overview of transversal design principles ............................................................................ 36 Table 12: The meaning of each advisory in the Basic AMAN. .............................................................. 67

List of figures

Figure 1: Overview of the guidance material and the questions it replies to ........................................ 15 Figure 2: The new ‘Levels of Automation Taxonomy’ (LOAT) .............................................................. 27 Figure 3: Overview of steps to apply the guidance on automation design. .......................................... 28 Figure 4: Example of a CWP................................................................................................................. 40 Figure 5: Ex. of Navigation Display, with indication of the position of other a/c on taxiways. .............. 43 Figure 6: Example of basic and extended configuration of the track label ........................................... 45 Figure 7: The Track Termination Warning. ........................................................................................... 47 Figure 8: Ex. of ‘ERATO filtering’ highlighting potential intruders of a specific flight. ........................... 50 Figure 9: Ex. of ‘ERATO What-If’ used to plan a re-routing. ................................................................. 50 Figure 10: Example of ATSAW ITP indications displayed on the cockpit. ............................................ 51 Figure 11: Example of a BTV interface for a landing at CDG ............................................................... 52 Figure 12: The PPD Display of MTCD. ................................................................................................. 55 Figure 13: The visualization of the conflict on the main radar screen. ................................................. 55 Figure 14: Example of conflict visualized on the Executive Controller main radar screen. .................. 56 Figure 15: Example of a generic STCA alert HMI. ................................................................................ 56 Figure 16: Example of multi-hypothesis processing by A-STCA for flights in final approach. .............. 57 Figure 17: Triggering conditions of BTV ROW/ROP function. .............................................................. 58 Figure 18: An example of MTCD alert on the left side and of ECS warning on the right side. ............. 60 Figure 19: Examples of ECS Flight Path Monitoring alerts for FL deviation on the left side and for

cleared route deviation on the right side. ....................................................................................... 61 Figure 20: Examples of ERATO Monitoring function alerts, for horizontal deviation on the left side and

for vertical deviation on the right side. ........................................................................................... 61 Figure 21: An example of visual MSAW alert. ...................................................................................... 63 Figure 22: An example of track with visual MSAW alert de-activated .................................................. 63 Figure 23: An example of the SARA advisories in a track label. .......................................................... 66 Figure 24: Graphical representation of a typical PMS procedure. ........................................................ 67 Figure 25: Two examples of advisories used in the Basic AMAN HMI. ................................................ 67 Figure 26: Two examples of advisories used in the Advanced AMAN HMI. ........................................ 68 Figure 27: Triggering conditions of BTV ROW/ROP function ............................................................... 71 Figure 28: The AMAN Master View Window......................................................................................... 74 Figure 29: Two examples of advisories used in the first AMAN HMI. ................................................... 75 Figure 30: The choice of the manoeuvre is done by the controller and instructed to the flight crew. ... 77 Figure 31: Triggering conditions of BTV ROW/ROP function. .............................................................. 79 Figure 32: The TCAS RA on Primary Flight Display without AP/FD TCAS mode. ............................... 80 Figure 33: The TCAS RA on Primary Flight Display with AP/FD TCAS mode. .................................... 81 Figure 34: Safe altitude capture with AP/FD TCAS mode. ................................................................... 81 Figure 35: Example of unmanned train coach of the Metro transportation system in Toulouse. ......... 83 Figure 36: Example of a Toulouse Metro station with glass barriers. ................................................... 84 Figure 37: What-if probing for flight levels displayed in the CFL menu. ............................................... 86 Figure 38: What-if probing for directs. ................................................................................................... 86 Figure 39: Example of a graphical taxi route display for taxi-out operation on Paris CDG airport. ...... 87


6 of 97

Figure 40: Indications on the Primary Flight Display (PFD). ................................................................. 89 Figure 41: The execution of the RA avoidance manoeuvre with its aural and visual feedback provided.

....................................................................................................................................................... 90 Figure 42: Example of the BTV indication in the Flight Mode Annunciator. ......................................... 92 Figure 43: The Navigation Display. ....................................................................................................... 92


7 of 97

Executive summary

Automation is expected to play a critical role in the proposed change of the European ATM system. In the context of SESAR, it may enhance several ‘Key Performance Areas’, including safety, security, capacity, efficiency, and cost-effectiveness. Automation is envisioned to support human actors in the ATM system both by taking full advantage of technical solutions and by enhancing human performance.

This document is the condensed version of the deliverable “Guidance Material for HP Automation Support”. It provides guidance on automation design and evaluation that HF specialists can apply to airborne and ground operational and technical projects involving automation. The document is also useful for readers interested in gaining a better understanding of the value of human factors in automation design.

Guidance is proposed mainly for three HP activities relevant to automation design:

Identifying potential human performance automation issues that may emerge as a result of the introduction of automation support, and which are considered to be specifically relevant to the SESAR Target Concept of Operations.

Identify the appropriate level of automation for an existing or targeted automation with a new level of automation taxonomy

Support HP with principles on automation design.

The material here was developed within the different tasks of WP 16.5.1 using different methods. Human Performance automation issues considered relevant to the SESAR target were identified by a review of the SESAR ConOps and other SESAR documents, a literature review of HF research conducted on automation in both aviation-related and non-aviation domains, and interviews with operational experts and HF experts to gather specific SESAR-related examples of the automation issues relevant to ground, air and air-ground systems.

Levels of automation represent a key aspect to analyse and compare automation examples and to further derive automation design principles relevant in SESAR based on successful automation examples. A new level of automation taxonomy has been developed by the HF specialists involved in the 16.5.1 project to account for different cognitive functions which can be automated.

Relevant examples of automation of both airborne and ground domain have been analysed and compared with a customised template covering essential questions around a successful automated function. This collection of more than 20 relevant examples of automation served as an empirical basis to derive lessons learnt. In abstraction of this empirical basis and other well-known automation examples, the presented automation design principles were developed. These automation design principles are put in relation with the particularly concerned automation levels.

In general, this guidance material is supposed to influence the design and validation of automation aspects of projects going through phase V1 to V3. However, the earlier this material is applied in a project, the more efficiency it will enable, because the degrees of freedom for an initial and systematic definition of the automation level will be higher in earlier stages. Depending largely upon the specific automation solution in question and the project progress, the HF specialist can assess which of the proposed guidance is the most relevant for his/her activity at a certain stage.


8 of 97

1 Introduction

1.1 The need for automation

The advantages of automation are fairly obvious and usually concerned with economic and social considerations to improve overall system and human performance. Automation is intended to reduce the workload for humans and support system operations by reducing (human) errors. Automation is expected to play a critical role in the proposed change of the European ATM system and in the context of SESAR it may enhance several ‘Key Performance Areas’ including safety, security, capacity, efficiency and cost effectiveness.

The use of automation is envisioned to support human decision-making, detect critical situations and balance the constraints and demand of ATM operations. Although the specifics have yet to be defined, the operational concepts in SESAR assert that humans and automated systems will cooperate to achieve the desired operational effectiveness and safety. "SESAR D3 - The ATM Target Concept" (SJU, 2007) states:

Humans will be central in the future European ATM system as managers and decision-makers. In the ATM Target Concept it is recognised that humans (with appropriate skills and competences, duly authorised) will constitute the core of the future European ATM System’s operations. However, to accommodate the expected traffic increase, an advanced level of automation support for the humans will be required.

To ensure that automated systems fit with the vision of the human in the ATM Target Concept, SESAR (SJU, 2007) will adopt the following high-level automation principles, which are based on a human-centered approach to automation design, development, and implementation:

Automate only to improve overall system and human performance, not just because the technology is available.

Examine the overall impact of automation before implementation to avoid additional complexity, loss of appropriate situation awareness or increase of errors.

Achieve balance between the efficiency created by automation and the human capability to recover from non-nominal and/or degraded modes of operations (automation failure strategy).

Place the human in command. The human will be the automation manager and not the automation monitor. Automation will assist humans to carry out their tasks safely, efficiently and effectively. Furthermore, the delegation of authority to machine should be clearly defined in all operational situations.

Minimise the potential for errors, mainly by regulating workload and providing tools to help humans organise their work and make the right decisions.

Automation should be error-resistant and error-tolerant.

Involve users in all phases of system design to ensure benefits for overall system performance and to foster trust and confidence in the automation functions.

Consider the respective typical strengths and weaknesses of humans and of technology when deciding what to automate.

1.2 Problems associated with automation

Although automated systems clearly present advantages, research and experience with these systems indicate that failure to adopt a human-centred approach to the design, development, and implementation of automation support may result in a number of problems.

Problems may result due to the changes to system operators’ roles, tasks and responsibilities. For example automation is often introduced in a piecemeal approach where whatever can be automated is automated in unsystematic way and little regard is given to the role of the human and the set of task left for the human to perform. This can lead to the end users being left with a set of tasks that are


9 of 97

disparate, incoherent and un-meaningful and can result in an increase in the end users cognitive workload. This may result in acceptance of the automation and job satisfaction being reduced. Alternatively end users may become complacent or over-reliant on the automation. Complacency, or over-trust in an automated system may cause users to miss automation failures, especially if failures are rare.

The allocation of certain tasks to the system may also lead to the operators becoming deskilled, as skills deteriorate when they are not used. The implication of skill loss is that when an operator is forced to take over an automated system manually, he or she is likely to do so with minimal information and skill. This highlights an often unforeseen problem relating to the impact of the automation in abnormal conditions or in degraded modes of operations. Operators may perform effectively with automated systems during normal conditions, but during abnormal conditions, they tend to not always react appropriately to the failure of automated systems. This has been referred to as the “out-of-the-loop performance problem” or the “out of the loop unfamiliarity problem”. There are several possible reasons for this problem. Loss of skill, poor feedback, and complacency may all contribute to the ‘out-of-the-loop’ problem.

Changes to operators’ roles and tasks will result in changes to the way in which the end users and system interact. Hence, consideration must be given to the human machine interface to ensure it supports the end users in their new or changed tasks and roles. For example, poor or lack of feedback from the system to the user makes it difficult for the user to understand how the automated system is functioning. One reason automated systems fail to adequately inform the users of their actions is that the automated systems place an additional layer of complexity (data processing, data fusion, and intelligent control) between the actual system processes and sensory data the user is controlling. Furthermore, complex automated systems often operate in a number of different modes in which the behaviour of the system is slightly different for each mode of operation. Users could find themselves unaware of the current mode of the system and, as a consequence, be surprised by the system behaviour. The transition between modes may occur automatically, making it even more difficult for the human to remain aware of the current mode of the system.

1.3 Structure of the guidance material

The guidance material is composed of the following documents:

1. The “Guidance Material for HP Automation Support”. 2. The “Annex A - List of REOAs”, which includes the relevant experiences of automation being

analysed. 3. The present “Guidance Material for HP Automation Support (Condensed Version)”, which

includes the same contents of the full guidance document in a shorter version.

The present condensed version of the guidance document is structured in the same way as the full version. However all the chapters have been shortened to provide a quick reference on how to use the guidance, with limited background information.

Chapter 2 explains who and how this material is meant to provide support in automation design also in reference to the Human Performance Assessment Process applied within SESAR. Chapter 3 provides guidance on determining automation and identifying the HP automation issues. A list of HP automation issues is presented. Chapter 4 presents a new taxonomy of automation and a method to apply it in automation design. Chapter 5 provides specific guidance on automation design principles, based on the taxonomy identified before.

For a full understanding of the guidance material it is necessary to read the full version of the document. Nonetheless, thanks to the unmodified structure of chapters, the reader who prefers to start with the condensed version may decide to jump to the corresponding chapter of the full version as needed. Please also note that Chapter 5 (Automation Design Principles) is unchanged from one version to the other. While the original Chapter 6 (Guidance on Methods for HP Automation Support Evaluation) is available only in the full version.


10 of 97

1.4 Acronyms

Term Definition

ACC Area Control Centre

ACT-R Adaptive Character of Thought—Rational

ADD Aircraft Derived Data

ADS-B Automatic Dependent Surveillance-Broadcast

AIS Action Implementation Support

AIM Automation Impact on Mental workload

AL Automation Level

AMAN Arrival Manager

AP/FD (TCAS) Auto Pilot/ Flight Director (TCAS)

APM Aircraft Path Monitor

APP Approach

APW Area Proximity Warning

ASAS S&M Airborne Separation Assistance System – Sequencing & Merging

A-SMGCS Advanced Surface Movement Guidance and Control System

ASPA Airborne SPAcing

ATC Air Traffic Control

ATCO Air Traffic Controller

ATIS Automatic Terminal Information Service

ATIMS Air Traffic and Information Management System

ATM Air Traffic Management

ATSAW Air Traffic Situation Awareness

ATSAW SURF Air Traffic Situation Awareness during Surface Operations

ATSAW ITP Air Traffic Situation Awareness In Trail Procedure

BTV Brake To Vacate

CATO Controller Assistance Tools

CATO ECS Executive Conflict Search

CATO FPM Flight Path Monitoring


11 of 97

Term Definition

CCTV Closed Circuit Television

CDA Continuous Descent Approach 72

CDT Conflict Detection Tool 60

CFL Cleared Flight Level 91

CPDLC Controller Pilot Data Link Communications

CTA Cognitive Task Analysis

CONOPS CONcept of OPerationS

CWP Controller Working Position

DAS Decision and Action Selection

DEL DELiverable

D-TAXI Data-link taxi clearance delivery

DSAM Down-linked Selected Altitude Monitoring

E-ATMS European Air Traffic Management System

EC Executive Controller

ERATO En Route Air Traffic Organiser

E-OCVM European Operational Concept Validation Methodology

E-TMA Extended TMA

E-TML Enhanced Task Monitoring Load

FAF Final Approach Fix

FASTI First ATC Support Tools Implementation

FL Flight Level

FMA Flight Mode Annunciator

FMS Flight Management System

GPWS Ground Proximity Warning System

HF Human Factors

HF High Frequency

HMI Human Machine Interface

HP Human Performance


12 of 97

Term Definition

HPAP Human Performance Assessment Process

IAC Information Acquisition

IAF Initial Approach Fix

IAN Information Analysis

ILS Instrument Landing System

ISA Instantaneous Self Assessment

KLM Keystroke-Level Model

KPA Key Performance Area

LOAT Level Of Automation Taxonomy

MCDU Multi-purpose Control and Display Unit

MONA Monitoring Aids / Advisory/

MSAW Minimum Safe Altitude Warning

MTCD Medium Term Conflict Detection

ND Navigation Display

NOTAM Notice to Airmen

OANS On-board Airport Navigation System

OSED Operational Services and Environment Definition

PC Planning Controller

PF Pilot Flying

PFD Primary Flight Display

PIR Project Initiation Report

PMS Point Merge System

PNF Pilot Non-Flying

POF Problem Oriented Flight

PPD Potential Problem Display

P-RNAV Precision Area Navigation

R&D Research & Development

REA Ready Message


13 of 97

Term Definition

REOA Relevant Experience Of Automation

ROP/ROW Runway Overrun Prevention and Warning System

RTS Real-Time Simulation

RWY Runway

SA Situation Awareness

SARA Speed And Route Advisor

SASHA Situation Awareness for SHAPE

SATCOM Satellite Communications

SATI SHAPE Automation Trust Index

SESAR Single European Sky ATM Research Programme

SHAPE Solutions for Human-Automation Partnerships in European ATM

SPR Safety and Performance Requirements

SSR Secondary Surveillance Radar

STCA Short Term Conflict Alert

TAT Turn Around Time

TCAS-RA Traffic Alert and Collision Avoidance System – Resolution Advisory

TCAS-TA Traffic Alert and Collision Avoidance System – Traffic Advisory

TCT Tactical Controller Tool

TMA Terminal control Area / Terminal Manoeuvring Area

TP Trajectory Prediction

TPO Tactical Parallel Offset Manoeuvre

TRA Transversal

TTL / TTG Time to Lose / Time to Gain

TTW Track Termination Warning

TWR Aerodrome Control Tower

UI User Interface

VALP Validation Plan

VALR Validation Report


14 of 97

Term Definition

VERA Verification and Resolution Advisory Tool

VFR Visual Flight Rules

VHF Very High Frequency

VSI Vertical Speed Indicator

WP Work Package


15 of 97

2 How to understand this guidance material The added value of this guidance material lies in supporting operational and technical projects with a strong focus on automation throughout their design and evaluation process.

This guidance material provides suggestions for the design of automation, with a focus on human-automation interaction and on the best way to support the human performance. It is designed to apply on a wide range of air and ground projects with no limitations to a specific automated function. After familiarisation with the material, it remains up to the expert of a specific project context to carefully assess which knowledge is relevant for the automation design in question and how it can positively contribute to the concerned project.

2.1 Overview of the material

This document provides guidance material to support automation design for airborne and ground automation from a Human Factors perspective. As illustrated in Figure 1 below, the material covers different topics with relevance for the design of automation including: guidance on Human Performance issues, the classification of the level of automation and the use of automation design principles associated to a certain level. Within each of the topics the material may help to answer the depicted questions.

Figure 1: Overview of the guidance material and associated questions

Accordingly, the material supports three relevant HF activities in terms of automation design:

Identifying potential human performance issues that may emerge as a result of the introduction of automation support and that are considered to be of specific relevance to the SESAR Target Concept of Operations.

Identifying the appropriate level of automation.

Providing automation design principles to facilitate the design of the HP automation support.

Guidance on HP issues

How to defineautomation?

Which are the relevant HP automation

issues ?

How to find the optimal

automation level?

Guidance on

Level of automation

Chapter 4

Guidance on Automation

design

Chapter 5

How to classifyautomation

levels?

How to classifyautomation

based on cognitive

functions?

Which is the best way to

support humanperformance?

Chapter 3


16 of 97

As anticipated before, the topics in the first 2 bullet points above are only presented in the form of a quick reference in this condensed version of the guidance material. The reader interested in a full understanding of the contents, with adequate background information, should better refer to the corresponding chapters 3 and 4 in the full version of the document.


17 of 97

3 Guidance on Automation and Automation Issues

3.1 Determining Automation

Automation comes in many different forms and there is a wide range of system characteristics and capabilities that may be classified as automation. Automation can be thought of as the process and the result of allocating activities to a machine or system to perform which have been performed by humans in the recent past.

Thus, the widely accepted Wickens’ et al. [16] definition of automation is used, in which automation is referred to as ' a device or system that accomplishes (partially or fully) a function that was previously carried out (partially or fully) by a human operator’. Note that in some cases the introduction of automation does not only imply partial or full replacement of the former activity of a human operator. Alternatively the automation, as a new team player, can be in charge of completely new tasks, such as in the case of airborne automation performing self-separation manoeuvres. The self-separation manoeuvre is performed by automation but was not previously carried out by a human operator. For such cases we refer to a ‘new’ task performed by automation or with the support of automation.

HP activity: Determining automation

To identify the specific automation, the HF specialist may consider the following aspects:

It is crucial to address automation in relation to human performance, i.e. the automation to be

analysed is not just a technical improvement but has an impact on how the human is supported in his/her task accomplishment.

Another indicator is that the target automated solution may also lead to a change in how the

human is supported or in how human and machines interact. Such change could concretely concern the nature of tasks, roles or responsibilities of the involved actors, working procedures. These in turn imply consequences on human performance (e.g. workload, situation awareness). In a broader sense, the automation may also have an impact on ATM.

When addressing automation it is important to distinguish the overall automated system from a

specific automated function. A system is understood as a collection of components organised to accomplish a specific function or set of functions. For example, an airborne automated system would be Traffic Alert and Collision Avoidance System (TCAS) which comprises certain functions. These specific functions could be the TCAS Resolution Advisory (RA) or TCAS Traffic Advisory (TA). From ATC side, ERATO (En-route Air Traffic Organizer) can be understood as a system that incorporates different integrated functions, such as the Filtering function or the What-if function.

3.2 Identifying HP Automation Issues

To facilitate the HF specialist in his/her reflection on HP automation issues, it may be useful to think about a number of topics that are in close relationship with automation. Below are provided 29 issues grouped in five different topics relevant in the context of automation.

For further information on how the issues were elaborated and for concrete air-and/or ground examples please refer to Chapter 3 in the full version of this document.

3.2.1 Role changes and task allocation (issues 1 to 7)

The introduction of automation may cause significant changes to end users existing roles and responsibilities, as tasks (partially or fully) previously performed by the human operators will performed by a system or device. Failure to consider human capabilities and limitations when allocating tasks and functions during the development of the automation may result in human strengths not being exploited. This in turn may result in both human and system performance being


18 of 97

significantly degraded in some way. Furthermore, existing team interaction may be jeopardized if disregarded during automation design processes.

Table 1: Examples of Automation Issues on role changes and task allocation

1. Lack of user involvement in automation assisted processes may lead to reduced vigilance and loss of situation awareness.

2. Lack of user involvement in automation assisted processes may lead to loss of skills and proficiency.

3. Lack of user involvement in automation assisted processes may impact recovery from system failure.

4. Lack of user involvement in automation assisted processes may decrease motivation and job satisfaction.

5. The automation of routine tasks may remove an important information source which may reduce situation awareness.

6. Changes and variability in task distribution may cause confusion, with negative impact on air-ground collaborative work efficiency and even lead to errors of omission or commission.

7. Automation may impact the roles and tasks within a team and require changes to the working environment.

3.2.2 Working method and task changes (issues 8 to 14)

The introduction of automation support may have an unforeseen impact on the operators’ tasks and working methods. These changes may inadvertently lead to an increase in the operators’ workload or reduce their situation awareness and negatively impact human performance especially in terms of efficiency and safety. If safety and efficiency is perceived to be negatively impacted by the introduction of automation the operators will be less likely to accept and use the automation support introduced. As a result, the impact of automation on operators’ tasks and working methods must be assessed to ensure that the automation provides the required support to the operators and that human performance is not negatively impacted in any way.

Table 2: Examples of Automation Issues on working method and task changes

8. Automation support for decision making may be based on too simplistic algorithms and parameters to cope with the complexity of the operational environments inducing workarounds and higher workload in human operators.

9. Progressive shift from skill/rule-based task to knowledge-based tasks may result in increased response times or increased risk of errors by operators.

10. Automation may increase task demand and cognitive workload.

11. Automation could require additional system inputs, which may lead to increased task load and reduced acceptance.

12. Poorly designed automation may lead to simultaneous tasks competing for user attention or causing interruptions of high workload activities, reducing efficiency and increasing the risk of human error.

13. Specific automation supporting monitoring activities may lead to excessive ‘head down’ time at the expense of ‘out of the window’ checks by both pilots and tower ATCOs, with potential negative impact on human performance.

14. Loss of flexibility in automated systems will reduce the human potential to adapt to normal and abnormal situations.


19 of 97

14b. Systems that do not consider unexpected events nor update the planning may lead to loss of situation awareness and to increased decision times.

3.2.3 Information presentation in human-machine interaction (issues 15 to 20)

The introduction of automation may change which information the end users need to support their own work. Such changes must be considered in the development of the automation and this raises certain issues relating to the utility and usability of the information presented to the end users.

Typical questions to be answered include: a) whether automation is triggered manually by human actor or by an electronic sub-system, under which circumstances and how to ensure that the users are informed and aware of the mode of operation; b) whether feedback regarding the current operating mode of the system or ongoing changes in the operating modes is presented in a sufficiently clear manner for the user to detect it; c) whether information is mandatorily displayed to operators or explicitly requested by them; d) which part of the information concerning the internal functioning of the automation is worth being presented to the operator and which should be filtered out to ensure adequate control of the interaction, whilst avoiding cognitive overload.

Table 3: Examples of Automation Issues on information presentation in HCI

15. Data fusion and filtering in automated support systems may reduce ATCO and pilots’ accessibility to relevant information, with negative impact on decision making processes and situation awareness.

16. Poor usability of HMI may reduce the human performance benefits expected from the automation support.

17. Information flooding due to poorly designed automation support may impact situation awareness and increase cognitive workload.

18. New automation support that results in greater use in visual information may lead to visual channel overload, with decrease in situation awareness and performance efficiency.

19. Lack of awareness of mode of operation may reduce efficiency and increase the risk of human error.

20. Automation intervention impacting on both air and ground operators but interacting with only one of the two actors may jeopardize air-ground interoperability, increasing the risk of unsafe acts by both ATCOs and pilots, caused by confusion regarding responsibility for authority.

3.2.4 Trust and system reliability (issues 21 to 25)

Operators’ trust in automatic systems affects how and if automatic functions are used. If operator trust exceeds automation’s capabilities, problems of misuse or complacency can occur. On the other hand if operators’ trust in the automated system is insufficient, too limited use or disuse will reduce the expected benefits. Besides, in a majority of cases, an insufficient reliability of the automation will negatively impact the trust of operators.

The trust in an automated system is also impacted by liability aspects. When relevant decisions or actions will be made based on decisive automation support, operators may require adequate assurance that they will not be blamed for an unsafe decision or action previously delegated to automation.

Table 4: Examples of Automation Issues on trust and system reliability

21. Lack of trust in automation may induce misuse, disuse or abuse of automation.

22. Excessive trust in monitoring automation support may lead to complacency and reduced


20 of 97

situation awareness.

23. Inadequate trade-off between nuisance/false alerts and warning time may cause mistrust in automation and increase workload.

24. Pre-existing liability framework may result inadequate to increased automation-assisted decision-making, leading to user reluctance to use it and reduced safety/performance benefits.

25. New communication systems that will change working methods may lead to new types of errors.

3.2.5 Communication (issues 26 to 28)

The introduction of automation may enable new ways of communicating between different operators and modify relevant characteristics of the communication itself, such as: the communication channel (from aural to visual or vice-versa); the communication lines (from one-to-many to one-to-one and vice-versa) and the temporal dimension (from ephemeral to stable and vice versa). For example, data exchanges between air and ground will be increasingly performed by data-link, while voice is expected to remain as back up in time critical circumstances. This will have a profound impact on communication and team interaction. Failures to anticipate the different impacts of these communi-cation modes on individual’s and team situation awareness and workload or to consider their fit-for-purpose to specific operational situations may generate new forms of errors or limit the expected performance and safety benefits.

Table 5: Examples of Automation Issues on communication

26. The use of data-link communication will impact task sequencing and working methods, hence may increase memory load.

27. New communication systems may increase automated data exchange, leading to decrease situation awareness of pilots and ATCOs.

28. Change in communication channel from auditory to visual may negatively impact ‘team’ situation awareness, leading to reduced performances and increased risk of error.


21 of 97

4 A new level of automation taxonomy and a method to apply it

This chapter presents a new level of automation taxonomy (LOAT) and secondly, proposes a method how to apply LOAT and to identify the appropriate level of automation.

The level of automation taxonomy is useful to analyse and to compare automation by understanding its nature in detail. In principle, automation is not either ‘all or nothing’ and in this context several different levels of automation may be identified. These levels help to identify in which degree a task is automated, on a continuum from a low level (i.e. no system assistance) to a high level (i.e. completely automated system).

Tasks usually performed by human operators may be partially or fully automated. The automation may become in charge of either all or parts of the tasks previously attributed to humans or part of new tasks (that were previously not performed by the human). The automation level determines the type human and automation cooperate.

Note that it is essential to understand the new LOAT to proceed with the guidance provided in Chapter 5 to apply automation design principles related to specific automation levels.

4.1 LOAT: A new level of automation taxonomy

This subchapter presents the new level of automation taxonomy and its essential principles. For further information on the origin and background of the LOAT please refer to Chapter 4 in the full version of this document.

4.1.1 The cognitive functions to be supported by automation Based on a human information processing model, a simple 4 stage model of cognitive functions is here proposed as part of the LOAT. The four cognitive functions are defined in Table 6 below and associated to a set of concrete examples. These examples establish a link between existing automations and the cognitive functions that are supported. It is worth noting that the examples (air and ground automations) are not intended to be exhaustive and include both current operational automations and tools being widely studied in recent R&D programmes and projects.


22 of 97

Table 6: Cognitive functions and examples of automation in support

Stage Cognitive Functions Definition of automation support provided to a cognitive function

Air example: Ground example:

1 Information Acquisition (IAC) Acquisition and registration of multiple sources of information. Initial pre-processing of data prior to full perception and selective attention.

A human operator follows an ongoing process and the automation supports her/him by collecting, aggregating and providing relevant information on this process.

Automation that supports information acquisition facilitates the possibility to follow the ongoing process by providing relevant information to the operator.

TCAS TA (including visual display of traffic and aural annunciation)

D-TAXI tool (including graphical route information)

ATSAW SURF with surrounding traffic information

Visualization of traffic on CWP through Multi-Radar Tracking System.

A-SMGCS airport moving map

2 Information Analysis (IAN) Conscious perception, manipulation of information in working memory. Cognitive operations including rehearsal, integration, inference.

Automation supports the user in analysing the available information regarding the process that the user is following.

In some cases the information analysis of the system can be requested by the operator or the automation can perform the analysis based on pre-defined criteria.

The system can inform the human when a certain result has been achieved and it is essential that the user is aware of it.

The automation combines and compares different elements in the process being analysed, e.g. the automation is not just informing the user about the position of an aircraft but qualifies that there might be a risk of proximity between aircraft.

ASAS S&M information display STCA-MSAW-APM-APW visual and aural alerts

A-SMGCS route-planning function

MTCD conflict alerting function

MONA alerts

A-SMGCS alerts

3 Decision and Action Selection (DAS) Selection among decision alternatives, based on previous information analysis. Deciding on a particular (‘optimal’) option or strategy.

The system provides options regarding a possible action to be performed and selects the appropriate one.

At a lower level of automation, the operator might have more visibility on options while at a higher level of automation the human operator might be less informed about the options.

Supporting this cognitive function, the automation selects a possible action to be executed among different alternatives.

Difference between IAN and DAS which can occur in parallel:

In information analysis the system performs or helps the operator to conduct the analysis, but it does not advise a possible action to be performed.

GPWS alerts

TCAS RA (including aural advisory and display of green/red vertical speed areas in VSI)

AMAN visualization of proposed sequence of aircraft

AMAN speed advisories


23 of 97

While in decision and action selection the operator is always provided with one or more resolutions for the problems s/he is addressing.

4 Action Implementation Support Functions (AIS) Implementation of a response or action consistent with the decision previously made. Carrying out the chosen option.

If the automation supports action implementation, the automation helps the human in performing the action. The automation can assist in two different ways:

either the automation partially or entirely replaces the operator in carrying out the action, or

the automation provides guidance while the operator is executing the action.

Autopilot

ASAS S&M Trajectory Guidance equipment

Corrective TCAS Resolution Advisory automatically flown by the new AP/FD TCAS mode proposed by Airbus

Automatic Flight Plan Correlation function

Automatic SSR code assignment function

What should be kept in mind is that these cognitive functions are a simplification of the many components of human information processing. From a practical point of view, the human operator may be performing a task which involves one or several cognitive function(s). The cognitive functions are not meant to be understood as a strict sequence, but they may temporally overlap in their processing. Considering this, it is essential to differentiate the subtleties between the cognitive functions when one wants to identify how a specific automated function supports the human; e.g. providing the result of an information analysis to be differentiated from providing explicit decision and action selection support.


24 of 97

4.1.2 Level of automation taxonomy: A set of automation levels for each cognitive function

The new proposed LOAT (Figure 2) is grouped by the four cognitive functions corresponding to the columns, namely: from Information Acquisition (column A), Information Analysis (B), and Decision and Action Selection (column C) to Action Implementation (column D). Each cognitive function groups a number of automation levels that was deemed suitable for each cognitive function, thus a different number of levels per cognitive function.

All columns start with a default level ‘0’ corresponding to manual task accomplishment. Level 1 is based on the principle that the human is accomplishing a task with ‘primitive’ external support which is not automation as such. Any means that support the human mind e.g. using flight strips to compare parameters of different aircraft and to pre-plan future traffic, could correspond on this intermediate level. The levels increase from manual over artefact-supported, a low, medium and high level of automation up to full automation. From level 2 and upwards, ‘real’ automation is involved.

Compared to Information Acquisition (A) and Information Analysis (B), the cognitive functions Decision and Action Selection (C) and Action Implementation (D) required more levels to be specific enough.

Furthermore in some cases the columns C and D cannot be considered as completely independent. As a matter of fact the last two levels of Decision and Action Selection (C5 and C6) can only be connected to a following Action Implementation not lower than D5. The reason for this is that these high levels of decision making include the possibility of not informing at all the human about the decision taken by the system. Therefore only those Action Implementation levels not requiring human initiation (from D5 upwards) can be associated to these levels.

This taxonomy is applicable not only in the field of automation in aviation but to any domain in which automation is present..

To facilitate comprehension of the design principles in the following chapter, it is recommended to print out the matrix as presented in Figure 2 below (or in ‘Annex A – list of REOAs’).


25 of 97

A INFORMATION ACQUISITION

B INFORMATION ANALYSIS

C DECISION AND ACTION SELECTION

D ACTION IMPLEMENTATION

A0

Manual Information Acquisition

B0

Working Memory Based Information Analysis

C0

Human Decision Making

D0

Manual Action and Control

The human acquires relevant information on the process s/he is following without using any tool.

The human compares, combines, and analyses different information items regarding the status of the process s/he is following by way of mental elaborations. S/he does not use any tool or support external to her/his working memory.

The human generates decision options, selects the appropriate ones and decides all actions to be performed.

The human executes and controls all actions manually.

A1

Artefact-Supported information Acquisition

B1

Artefact-Supported Information Analysis

C1

Artefact-Supported Decision Making

D1

Artefact-Supported Action Implementation

The human acquires relevant information on the process s/he is following with the support of low-tech non-digital artefacts.

Ex. 1) Identification of aircraft positions on an aerodrome/airport according to Procedural Air Traffic Control rules and without use of radar support.

The human compares, combines, and analyses different information items regarding the status of the process s/he is following utilising paper or other non-digital artefacts.

Ex. 1) Use of flight strips to compare altitudes/levels/planning times of different aircraft and to pre-plan future traffic.

The human generates decision options, selects the appropriate ones and decides all actions to be performed utilising paper or other non-digital artefacts.

The human executes and controls actions with the help of mechanical non-software based tools.

Ex. 1) Use of a hammer or leverage to increase the kinetic energy of human gesture.

Ex. 2) Use of a mechanical or hydraulic rudder to achieve a change in direction.

A2

Low-Level Automation Support of Information Acquisition

B2

Low-Level Automation Support of Information Analysis

C2

Automated Decision Support

D2

Step-by-step Action Support:

The system supports the human in acquiring information on the process s/he is following. Filtering and/or highlighting of the most relevant information are up to the human.

Ex. 1) Identification of aircraft positions in the airspace by way of Primary Radar working positions.

Ex 2). Use of video cameras to monitor traffic on airport’s area not visible from the Tower

Based on user’s request, the system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed.

Ex. 1) Activation by ATCOs of Speed Vectors for specific tracks on the CWP, in order to anticipate potential conflicts in a defined time frame.

Ex 2). Colour coding of traffic flows on ATCOs request

The system proposes one or more decision alternatives to the human, leaving freedom to the human to generate alternative options. The human can select one of the alternatives proposed by the system or her/his own one.

Ex.1) AMAN visualization of the proposed sequence of aircraft.

Ex.2) E-TML (Enhanced Task Monitoring Load) used by the Supervisor to identify the best configuration of sectors.

The system assists the operator in performing actions by executing part of the action and/or by providing guidance for its execution. However, each action is executed based on human initiative and the human keeps full control of its execution.

Ex. 1) A crane tele-operated by a human for construction works

Ex. 2) The aural and visual component of TCAS RA in current TCAS II version 7.0 (also LOA C5)

From INFORMATION to ACTION

IN

CR

EA

SIN

G A

UT

OM

AT

ION


26 of 97

A3

Medium-Level Automation Support of Information Acquisition

B3

Medium-Level Automation Support of Information Analysis

C3

Rigid Automated Decision Support

D3

Low-Level Support of Action Sequence Execution

The system supports the human in acquiring information on the process s/he is following. It helps the human in integrating data coming from different sources and in filtering and/or highlighting the most relevant information items, based on user’s settings.

Ex. 1) CWP allowing ATCOs to set flight level filters to display only certain traffic on the screen.

Based on user’s request, the system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed. The system triggers visual and/or aural alerts if the analysis produces results requiring attention by the user.

Ex. 1) ERATO Filtering and What-if function.

Ex 2). VERA Tool to display the closest point of approach between two aircrafts.

The system proposes one or more decision alternatives to the human. The human can only select one of the alternatives or ask the system to generate new options.

The system performs automatically a sequence of actions after activation by the human. The human maintains full control of the sequence and can modify or interrupt the sequence during its execution.

Ex. 1) Explicit initiation of an electronic coordination with adjacent sector via digital input (replacing use of telephone).

Ex. 2) ATCO’s input into the CPDLC of a clearance which is than transmitted to the a/c (replacing clearance sent via R/T).

A4

High-Level Automation Support of Information Acquisition

B4

High-Level Automation Support of Information Analysis

C4

Low-Level Automatic Decision Making

D4

High-Level Support of Action Sequence Execution

The system supports the human in acquiring information on the process s/he is following. The system integrates data coming from different sources and filters and/or highlights the information items which are considered relevant for the user. The criteria for integrating, filtering and highlighting the relevant information are predefined at design level but visible to the user.

Ex.1) D-TAXI tool (including graphical route information)

The system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed, based on parameters pre-defined by the user. The system triggers visual and/or aural alerts if the analysis produces results requiring attention by the user.

Ex. 1) MTCD visual alerts (allowing some tuning of parameters by the user)

The system generates options and decides autonomously on the actions to be performed. The human is informed of its decision.

Ex.1) Aural and visual component of TCAS RA in current TCAS II version 7.0 (also LOA D2)

The system performs automatically a sequence of actions after activation by the human. The human can monitor all the sequence and can interrupt it during its execution.

Ex.1) Acknowledgment by pilot of a clearance received trough CPDLC (data-link) and automatically sent to FMS and autopilot.

Ex. 2) Autopilot following the FMS trajectory.

A5

Full Automation Support of Information Acquisition

B5

Full Automation Support of Information Analysis

C5

High-Level Automatic Decision Making

D5

Low-Level Automation of Action Sequence Execution

The system supports the human in acquiring information on the process s/he is following. The system integrates data coming from different sources and filters and/or highlights the information items which are considered relevant for the user.

The system performs comparisons and analyses of data available on the status of the process being followed based on parameters defined at design level. The system triggers visual and/or aural alerts if the analysis produces results requiring

The system generates options and decides autonomously on the action to be performed. The human is informed of its decision only on request. (Note that this level is always connected to some kind of ACTION IMPLEMENTATION,

The system initiates and executes automatically a sequence of actions. The human can monitor all the sequence and can modify or interrupt it during its execution.

Ex. 1) Implicit initiation of an electronic co-


27 of 97

Figure 2: The new ‘Levels of Automation Taxonomy’ (LOAT)

The criteria for integrating, filtering and highlighting the relevant info are predefined at design level and not visible to the user (transparent to the user in Computer Science terms).

attention by the user.

Ex. 1) TCAS TA (including visual display and aural annunciation of intruding traffic)

Ex. 2) STCA visual and aural alerts.

Ex. 3) DSAM alerts.

Ex. 4) Trajectory prediction to display the Estimated Time Over a fix on an aircraft trajectory

at an automation level not lower than D5.) ordination with adjacent sector as agreed exit conditions (according to Letter of Agreement) cannot be met anymore after changes to the a/c trajectory (route or flight level) has been made.

C6

Full Automatic Decision Making

D6

Medium-Level Automation of Action Sequence Execution

The system generates options and decides autonomously on the action to be performed without informing the human. (Note that this level is always connected to some kind of ACTION IMPLEMENTATION, at an automation level not lower than D5.)

The system initiates and executes automatically a sequence of actions. The human can monitor all the sequence and can interrupt it during its execution.

Ex.1) TCAS AP/FD mode concept during execution of a corrective TCAS RA.

D7

High-Level Automation of Action Sequence Execution

The system initiates and executes a sequence of actions. The human can only monitor part of it and has limited opportunities to interrupt it.

D8

Full Automation of Action Sequence Execution

The system initiates and executes a sequence of actions. The human cannot monitor nor interrupt it until the sequence is not terminated.


28 of 97

4.2 Method to identify the level of automation and apply the design principles

The explanations on the level of automation taxonomy in the previous section 4.1 are necessary to understand and apply the design principles in Chapter 5. To take full advantage of the proposed guidance material on automation support design, we suggest following the steps in Figure 3. These steps refer to the guidance provided in different subchapters.

The HF specialist may proceed as follows:

1. First, determine ‘your’ specific automation which can be part of a system. Determine the automated function of interest which supports human performance (cf. 3.1).

2. Once the automated function is identified, make use of the definitions of the cognitive functions in Ch. 4.1.1 (theoretical part) and in the LOAT matrix in Ch. 4.1.2. Identify the prominent cognitive function(s) that ‘your’ automated function supports.

3. The descriptions of the automation levels and the examples in the LOAT matrix help then to identify the respective level of automation.

4. Having identified the level of automation, it is proposed to consult the concerned automation design principles (Ch. 5) which are presented for the different cognitive functions. Also consult the principles that may not be specific for one cognitive function but which apply in general to automation design (transversal design principles).

Figure 3: Overview of steps to apply the guidance on automation design.

The HF specialist has to bear in mind that depending upon the project progress, the material can be applied in both of the following cases:

The automated function exists already, so the respective automation level for this existing solution is under determination.

The appropriate automation level for a target automated function has to be determined. This implies that in this phase, it is still under definition in which way the automated function is supposed to support the human (i.e. which cognitive function is supported) and thus, which may be the most appropriate level of automation to enhance human performance by also taking highest advantage of the technical solution.

The first case may be the more usual one, while the latter one may occur in case the material is applied in a very early design phase or when the operational concept is under determination.

Ch

. 3.1 Determine the

automatedfunction whichsupports humanperformance

Ch

. 4.1

.1 Determine the applicable cognitive function(s)supported by the automatedfunction

Ch

. 4.1

.2 Identify the level of automation for the cognitive function(s)

Ch

. 5

Consider the automation design principles for the concernedcognitive function and transversal principles


29 of 97

4.2.1 Determine the applicable cognitive function(s) supported

HP activity: Determining the cognitive function supported by an automated function

Having determined the automated function supporting the human (cf. Chapter 3.1), the HF specialist can classify the associated cognitive function. An automated function can be associated to one or more applicable cognitive function(s). Determining the cognitive function helps to situate the support of a specific automated function in the appropriate columns.

In general, it is recommended to recall the definitions of all four cognitive functions, to identify the applicable cognitive function and also, if there is only one or several cognitive functions involved with the specific automation support.

Consider only the specific automated function (as part of an automated system)

e.g. TCAS: AP/FD mode; ERATO: What-if function.

Determine the cognitive function that the automated function supports the human in his task.

Consult the definitions of the cognitive functions earlier in this section and in section 4.1.1).

Bear in mind that there can be one or several cognitive function(s) that is/are associated to the

automated function support.

If the identified automated function is related to all four cognitive functions it may be a sign that

the automatic function determined so far involves still too many different sub-functions. It is recommended to reflect again and detail the automated function corresponding to a very specific task.

As a result, the HF specialist can ‘locate’ the appropriate column(s) of the LOAT matrix that his/her specific automated function applies to.


30 of 97

4.2.2 Identify the level of automation

HP activity: Identifying the (target) level of automation

After having selected the cognitive function, the HF specialist can focus on the applicable cognitive function and the respective column.

Consult all automation levels in one column, especially from low-level upwards (cf. above).

Find the appropriate level of automation by the description in each cell.

Verify adjacent automation levels to confirm your choice by exclusion. If possible, let another

project members rate the AL to see whether your choices are congruent.

What are advantages/disadvantages of a certain level that the HF specialist should bear in mind?

Consult the design principles specific to the relevant cognitive function(s)

(cf. sections 5.1 to 5.4) and the transversal principles (Section 5.5)

As a result, the HF specialist finds in which of the proposed automation levels he/she would classify his/her (target) automated function.


31 of 97

5 Automation design principles

This chapter provides the design principles which have been identified for each of the cognitive function: information acquisition, information analysis, decision and action selection, and action implementation support. In addition there are transversal design principles which may not be specific to a cognitive function but which apply in general to automation design.

For a general overview, all the design principles are summarised in this section in the four tables below containing only the title and the statement of the design principle.

Then, each design principle is explained in detail in the following sections:

Section 5.1: Design Principles for Information Acquisition Functions (IAC)

Section 5.2: Design Principles for Information Analysis Functions (IAN)

Section 5.3: Design Principles for Decision and Action Selection Functions (DAS)

Section 5.4: Design Principles for Action Implementation Support Functions (AIS)

Section 5.5: Transversal Design Principles (TRA)

As part of the explanation, ground and/or air examples of automations are presented in support of each design principle, when available from empirical data. The reader interested in analysing more in detail the examples of automated functions will find specific references to either the parent document ’Guidance Material for HP Automation Support. Annex A – List of REOAs’ or to other external web resources.

For each design principle we mention a number of relevant HP automation issues which can be addressed by applying the design principle. An overview of the issues identified in the context of this work can be found in Ch. 3.2. For further information on how the issues were elaborated and for concrete air-and/or ground examples please refer to Chapter 3 in the full version of this document.

It is worth noting that the first design principle of each of the main groups (IAC-IAN-DAS-AIS) is always concerning guidance on how to choose the most appropriate level of automation. In all groups this first principle always includes a set of sub-principles providing indications on specific automation levels derived from the LOAT taxonomy. However, as mentioned before, the levels 0 and 1 in the taxonomy are not considered as a real automation. Therefore the design principles refer only to the automation levels from level 2 and upwards.


32 of 97

Table 7: Overview of design principles for IAC

INFORMATION ACQUISITION (IAC)

IAC-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation for information acquisition tools when the concerned activity requires the processing of a limited number of information items by the human operator and when the information can be accessed through a limited number of information sources.

Prefer higher levels of automation support for information acquisition when the concerned activity requires the processing of an elevated number of information items by the human operator and when the information can be accessed through several information sources.

IAC-1.1: Choice of Automation Level A2

The AL A2 functions transmit information on the process to be followed without any filtering, highlighting and integration of the available data. These functions should be preferred when the two following conditions are met:

- the concerned activity requires the processing of a limited number of information items by the human operator

- the information can be accessed through a limited number of information sources.


The AL A3 functions transmit information on the process to be followed by integrating data from different sources and by filtering and/or highlighting the most relevant information items, based on user’s settings. These functions should be preferred when the two following conditions are met:

- the concerned activity requires the processing of an elevated number of information items by the human operator and/or the information can be accessed through several information sources

- the operational conditions and/or the tasks to be performed are variable and there is a need to monitor the process based on different integration/filtering criteria.

IAC-1.3: Choice of Automation Levels A4-A5

The AL A4-A5 functions transmit information on the process to be followed by integrating data from different sources and by filtering and/or highlighting the most relevant information items, based on parameters not adjustable by the user. These functions should be preferred when the following conditions are met:


- the operational conditions and/or the tasks to be performed are sufficiently stable and the associated processes can be monitored based on the same filtering/integration criteria.

IAC-2: RELEVANCE AND AMOUNT OF INFORMATION

Present to the user only essential information to perform the task and minimize the amount of information which is useless for the purposes of the task

IAC-3: AWARENESS OF SYSTEM LIMITATIONS

In case the information acquisition function does not have the capability to present operationally relevant information items, the user should be made aware of this limitation with appropriate HMI design solutions


33 of 97


34 of 97

Table 8: Overview of design principles for IAN

INFORMATION ANALYSIS (IAN)

IAN-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation support for information analysis tools when the automated function does not have the capability to compute relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for information analysis tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.

IAN-1.1: Choice of Automation Levels B2-B3

The AL B2-B3 functions provide the results of information analysis only on user request. These functions should be preferred when:

- there is no operational need for a systematic analysis of the concerned information or

- the internal logic of the automated function is not capable of processing relevant operational constraints and/or dynamic elements of the concerned operational environment, which may cause the automated function to activate when it is operationally inappropriate, thus causing disturbance and or excessive workload to the human operator


The AL B4-B5 functions perform systematic information analysis and trigger automatic alerts as appropriate. These functions should be preferred when the two following conditions are met:

- for operational reasons the user should be informed as soon as possible of critical results of the information analysis

- the internal logic of the automated function has the capability to process the most relevant operational constraints and/or dynamic elements of the concerned operational environment with an impact on the performance of the function, thus reducing the risk of triggering nuisance alerts to an effective minimum.

IAN-2: DEPENDENCY FROM USER INPUT

Minimize the dependency of information analysis tools from user input or keep the required human input to an effective minimum.

IAN-3: SUPPRESSION OF ALERTS

If the triggering of automatic information analysis alerts (AL B4 and B5) can be suppressed by the user, then make evident on the HMI that the alerting has been inhibited and define clear criteria establishing if and when the automatic alerts should be re-activated.


35 of 97

Table 9: Overview of design principles for DAS

DECISION AND ACTION SELECTION (DAS)

DAS-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation support for decision and action selection tools when the automated function does not have the capability to compute some relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for decision and action selection tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.

DAS-1.1: Choice of Automation Levels C2-C3-C4

The AL C2-C3-C4 functions leave more than one decision alternative to the human or do not allow any following action execution without human consensus. These functions should be preferred when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is based on a cooperation between the human operator and the automated function, maintaining the human fully in control of the situation.

DAS-1.2: Choice of Automation Levels C4 (with associated Action Implementation not

lower than D5)

The specific case of AL C4 related to action implementation not lower than D5 should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is delegating them to the automated function, leaving to the human operator only the possibility to interrupt the following action implementation.

DAS-1.3: Choice of Automation Levels C5-C6

The AL C5-C6 functions do not inform the human of the selected option or inform her/him only on request. These functions should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is delegating them to the automated function, leaving to the human operator only the possibility to interrupt the following action implementation.

DAS-2: AUTOMATION OVERRIDE

If the decision support by automation can be overridden by the user, then define clear criteria or mechanisms for reactivation or reinsertion of the automation support.


36 of 97

Table 10: Overview of design principles for AIS

ACTION IMPLEMENTATION SUPPORT (AIS)

AIS-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation support for action implementation tools when the automated function does not have the capability to compute relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for action implementation tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.

AIS-1.1: Choice of Automation Levels D2-D3-D4

The AL D2-D3-D4, which perform action implementation only after human initiation, should be preferred when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best strategy for action implementation is based on a cooperation between the human operator and the automated function, maintaining the human fully in control of the situation.

AIS-1.2: Choice of Automation Levels D5-D6

The AL D5-D6, which perform action implementation independently from human initiation, should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best strategy for action implementation is giving full power for execution to the automated function, leaving to the human only the possibility to interrupt the process.


AL D7-D8, which give limited or no opportunity to the human operator to monitor and interrupt an automated process, should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation in a physically protected environment, with limited risk of external interferences. In such cases the best strategy for action implementation is giving full power for execution to the automated function, leaving the human virtually out of the control loop, with limited or no possibility to monitor and interrupt the ongoing process.


37 of 97

Table 11: Overview of transversal design principles

TRANSVERSAL (TRA)

TRA-1: COMBINED SUPPORT TO COGNITIVE FUNCTIONS

When feasible, prefer HMI design solutions providing combined support to more than one cognitive function

TRA-2: FEEDBACK

Independently from the chosen automation level, an automated function should always provide a clear feedback in response to the inputs and actions by the user. Based on such feedback the user should always know:

- if the automation has actually received the input by the user

- if the action of the user has achieved the desired result or if progresses have been made in the direction desired by the user

TRA-3: MODE ERROR PREVENTION

When an automated function can be configured to work according to different modes, it is essential that the user is always made aware of the active mode and timely informed of any mode change. To the extent possible the HMI design should contribute to minimize the risk of mode errors.


38 of 97

5.1 Design Principles for information acquisition functions (IAC)

IAC-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation for information acquisition tools when the concerned activity requires the processing of a limited number of information items by the human operator and when the information can be accessed through a limited number of information sources.

Prefer higher levels of automation support for information acquisition when the concerned activity requires the processing of an elevated number of information items by the human operator and when the information can be accessed through several information sources.

This design principle is divided in 3 different sub-principles, referring to different groups of automation levels: IAC-1.1, IAC-1.2 and IAC-1.3.


The AL A2 functions transmit information on the process to be followed without any filtering, highlighting and integration of the available data. These functions should be preferred when the two following conditions are met:

- the concerned activity requires the processing of a limited number of information items by the human operator

- the information can be accessed through a limited number of information sources.

EXPLANATION

Compared to lower levels, the A2 level of information acquisition (IAC) requires a higher cognitive load by the user to select the information items which are more relevant to monitor a certain process and to perform the tasks associated to it. The automated function provides a digital support to the user to acquire information that will not be accessible otherwise (e.g. for a visual acquisition process, the automation will display information not visible to the naked eye). However all the available information is provided without any filtering and in case there is more than one information source, the user will be required to access them separately.

On the one hand the higher level of cognitive load of the human operator required by this AL may negatively impact the precision and speed of information acquisition, leaving room to potential errors or omissions when the number of information items to be considered exceeds a certain threshold. In such cases the ability of the user to focus her/his attention on the most important information items is completely dependent on her/his selective attention skills, which are mostly developed based on experience. On the other hand each information item is provided with a very high and fine grained level of detail, allowing the user to detect also minimal changes and intervening factors in the operational context. If the user is not distracted by other information elements, such richness of the information provided may help in the early detection of potential risks for safety as well as in the identification of opportunities to improve the efficiency of operations.

At design level it is preferable to choose this AL if the activity to be supported by the automation can be managed by the human operator by acquiring a limited number of information items and by accessing a limited number of information sources.

Investigated Examples

Ground Video cameras for surveillance of certain areas of an airport (Not in


39 of 97

REOAs)

Airborne Not available

Video cameras for surveillance of certain areas of an airport

An example of basic automated function supporting information acquisition at AL A2 is the use of CCTV (Closed Circuit Television) video cameras. As a matter of fact a video camera allows the user to monitor an area which is too far away or covered by visual obstacles. By definition a single video camera is able to show what is happening only in a limited area, although the visualization can be considerably detailed. Actually everything which is appearing in the area covered by the camera is visualized with no filtering, no highlights of specific information items and no integration of information coming from different sources.

The video cameras are known to be intensively used for security reasons in airports to monitor the behaviour of passengers and airport operators inside or outside the airport buildings, while they are seldom used for operational reasons by the air traffic controllers. However cases are reported of video cameras used to complement the out-of-the window scan by Tower and Ground controllers in airports in which part of the runways, taxiways or stands/packing positions are not easily visible by the naked eye. Although such solutions are normally associated to an inadequate design of the aerodrome and cannot replace the use of ground radars in case of low visibility, the use of video cameras can be still classified as a basic example of automation supporting the tasks of an air traffic controller.

Design implications

As anticipated the use of video cameras for monitoring purposes can be classified as an information acquisition function at AL A2. It provides a quite detailed view of the process being monitored, but it is a good design solution only when the user is not expected to monitor a huge number of information items and when there is no need to observe them in the wider picture (e.g. when it is only used to complement the out-of-the-window scan to monitor very small areas of the airport). Since by definition the video does not imply any filtering nor integration of information coming for different sources, the selective attention processes activated by the controller are the only means to distinguish relevant and irrelevant information items, resulting in a considerable amount of cognitive resources being spent.

Available REOAs

Not Available

External References

Not Available

HP AUTOMATION ISSUES BEING ADDRESSED

10) Automation may increase task demand and cognitive workload

12) Poorly designed automation may lead to simultaneous tasks competing for user attention or causing interruptions of high workload activities, reducing efficiency and increasing the risk of human error

13) Specific automation supporting monitoring activities may lead to excessive ‘head down’ time at the expense of ‘out of the window’ checks by both pilots and tower ATCOs, with potential negative impact on human performance

15) Data fusion and filtering in automated support systems may reduce ATCO and pilots’ accessibility to relevant information, with negative impact on decision making processes and situation awareness.


40 of 97

IAC 1.2: Choice of the Automation Level A3

The AL A3 functions transmit information on the process to be followed by integrating data from different sources and by filtering and/or highlighting the most relevant information items, based on user’s settings. These functions should be preferred when the two following conditions are met:


- the operational conditions and/or the tasks to be performed are variable and there is a need to monitor the process based on different integration/filtering criteria.

EXPLANATION

Compared to the lower level A2, this level of information acquisition (IAC) requires a lower cognitive load by the user to select the information items which are more relevant to monitor a certain process and to perform the tasks associated to it. The automated function support the selective attention processes activated by the user in different ways: (a) by giving to him/her the possibility to filter out the data which are not useful to monitor and operate on the process; (b) by giving to him/her the possibility to highlight the data which are more relevant to monitor and operate on the process; (c) by integrating the data coming from different information sources. However, compared to the higher levels A4 and A5, this level of information acquisition (IAC) requires a slightly higher cognitive load by the user to configure and adjust the integration and filtering criteria. Such criteria may be adjusted depending on the specific operational context in which the automation is used and on the specific tasks to be supported.

On the one hand the lower level of cognitive load of the human operator required by this AL and the possibility to adjust the automated function features (filtering, highlighting and integration) may positively impact the precision and speed of information acquisition, preventing the risk of potential errors or omissions when the number of information items to be considered exceeds a certain threshold. On the other hand the lower level of detail of the available information may prevent the user from detecting minimal changes and intervening factors in the operational context also when her/his attention is focussed on the relevant information elements. In addition the possibility to configure the automation features may open a window of opportunities for mode errors. E.g. the user may not realize that a certain category of information elements is filtered out due to a previous setting which was chosen in a different operational condition but is not appropriate to the ongoing one.

At design level it is preferable to choose this AL if the activity to be supported by the automation requires the processing of an elevated number of information items deriving from different information sources. Furthermore this AL should be preferred when it is not possible or not cost efficient to design a set of filtering, highlighting and integration features which are fit for all the operational conditions and which allow the execution of all the different tasks supported by the automation.


Ground CWP Altitude Filter and Zoom (not in REOAs)

Airborne Cockpit surveillance of the weather or traffic (not in REOAs)

CWP Altitude Filter and Zoom AL A3


41 of 97

A state of the art CWP (Controller Working Position) is a good example of a system that supports the user information acquisition by integrating data coming from different sources, by filtering them and by highlighting the information items which are considered more relevant. As a matter of fact the multi-radar tracking system behind a CWP allows the integration and visualization of surveillance data coming from different radars. Such data are also filtered by definition, since the secondary radar systems are normally displaying only tracks associates to those aircraft and aerial systems which are equipped with an active transponder. Finally nowadays CWPs also allow the visualization in different colours of traffic with different relevance, such as a brighter colour for the flights currently under control in the concerned sector and a less intense colour for the flights which have already left the concerned sector or are going to leave it.

Figure 4: Example of a CWP.

A CWP is also a system allowing the user to set and configure the information acquisition features to accommodate for different needs. The altitude filter and the zoom are just two examples of functions that can be adjusted based on controller’s input.

Actually when in a control centre a portion of airspace is covered by more than one sector on the vertical plane (e.g. one sector controlling below FL310 and another sector controlling above this FL), the ATCOs are normally allowed to filter out the visualization or those tracks which are below or above the flight level band of their interest, based on the altitude information provided by Mode C transponders. In this way they can reduce the cognitive load associated to the visualization of all the aircraft and make easier the selective attention processes which are normally activated.

In addition to this the ATCOs are allowed to set the zooming of their screens depending not only on individual preferences, but also on the specific tasks they need to perform. For example an Executive Controller is normally used to set the zoom in a way to visualize a smaller portion of the airspace, due to the need to focus on the tactical interventions to make on the specific traffic under her/his control. On the other hand a Planning Controller is normally used to adjust the zooming to visualize a much wider portion of the airspace in order to facilitate the monitoring of the borders of her/his sector and the coordination with the neighbouring ones.

Design Implications

Based on the characteristics illustrated above the altitude filter and the zooming functions make the CWP an automated function providing support to the user at AL3. The possibility to set differently these features is essential to accommodate for different operational needs with the same equipment (e.g. strategic vs tactical control). On the other hand the users should be fully aware of the risks associated to an erroneous configuration of these features. For example the erroneous setting of the altitude filter or of the zooming may lead the controller to disregard traffic which has already entered her/his sector. This might represent a serious hazard determined by an individual controller, but may also have an impact on other controllers during a shift change if the mistake is not timely detected.

Cockpit surveillance of the weather or traffic

Though no concrete REOA is currently available, it can be stated that in principle AL A3 exists in specific systems of the cockpit. For example, there are systems, such as the one dedicated to the surveillance of the weather or traffic, in which some functions allow a sort of filtering/highlighting of


42 of 97

relevant information, based on the human settings. They integrate all available data but according to the operational situations (e.g. flight phase, FL change), the human is able to decide to filter some of them based on criteria (e.g. altitude).

Available REOAs

Not available

External References

Not available


8) Automation support for decision making may be based on too simplistic algorithms and parameters to cope with the complexity of the operational environments inducing workarounds and higher workload in human operators.

7) Automation may impact the roles and tasks within a team and require changes to the working environment

10) Automation may increase task demand and cognitive workload.

14) Loss of flexibility in automated systems will reduce the human potential to adapt to normal and abnormal situations

15) Data fusion and filtering in automated support systems may reduce ATCO and pilots’ accessibility to relevant information, with negative impact on decision making processes and situation awareness

17) Information flooding due to poorly designed automation support may impact situation awareness and increase cognitive workload

IAC 1.3: Choice of Automation Levels A4-A5

The AL A4-A5 functions transmit information on the process to be followed by integrating data from different sources and by filtering and/or highlighting the most relevant information items, based on parameters not adjustable by the user. These functions should be preferred when the following conditions are met:


- the operational conditions and/or the tasks to be performed are sufficiently stable and the associated processes can be monitored based on the same filtering/integration criteria.

EXPLANATION

Compared to the lower levels, the A4-A5 levels of information acquisition (IAC) require a lower cognitive load by the user to select the information items which are more important to monitor a certain process and to perform the tasks associated to it. The automated functions support the selective attentions processes activated by the user in different ways: (a) by filtering out the information elements which are not useful to monitor and operate on the process; (b) by highlight the information elements which are more important to monitor and operate on the process; (c) by integrating the information elements coming from different information sources.

Furthermore, compared to the lower level A3, this level of information acquisition (IAC) does not


43 of 97

require any effort by the user to configure and adjust the filtering/highlighting and integration criteria to her/his own needs, since all these features are preset by design or automatically adjusted by the automation without any user intervention.

At AL4 the user is aware about the criteria for integrating, filtering and or highlighting the information items and about their possible limitations (e.g. specific cases in which a relevant information may be filtered out or in which irrelevant information is shown or highlighted). The user is informed about the criteria by making them visible in the design itself or by clarifying them in the context of a dedicated training.

At AL5 the criteria for integrating, filtering and/or highlighting the information items are ‘transparent’ and not visible to the user. The user is expected to focus on the information made available without any consideration nor critical review of the criteria adopted by the automation to select and integrate the data.

On the one hand the lower level of cognitive load of the human operator required by this AL may positively impact the precision and speed of information acquisition, preventing the risk of potential errors or omissions when the number of information items to be considered is very high. In addition the impossibility to configure and adjust the integration and filtering criteria gives no opportunity to the user to commit mode errors. On the other hand the lack of manual control and adjustments of such features may cause the automation to omit important information elements or to provide some of them when it is not operationally appropriate, with potential risks for the safety and efficiency of operations.

At design level it is preferable to choose these ALs if the activity to be supported by the automation requires the processing of an elevated number of information items deriving from different information sources. Furthermore this AL should be preferred when it is possible and cost efficient to design a set of filtering, highlighting and integration features which are fit for nearly all the operational conditions and which allow the execution of all the different tasks supported by the automation.


Ground Not available

Airborne AL A5: ATSAW SURF (Air Traffic Situation Awareness during Surface

Operations)

ATSAW SURF AL A5

ATSAW (Air Traffic Situation Awareness) is an onboard application to improve situational awareness by providing information about surrounding aircraft using Automatic Dependent Surveillance-Broadcast (ADS-B) position reporting. Via ADS-B an information exchange between aircraft is enabled; hence the flight crew obtains enhanced information about aircraft in vicinity. ATSAW SURF is one of the ATSAW applications supporting a better understanding of the traffic situation on the airport surface for both taxi and runway operations. More precisely, the function provides enhanced situation awareness of all traffic, vehicles and aircraft to the flight crew on the manoeuvring area of an airport and all aircraft flying in the vicinity of an airport. The enhanced information given on the displays completes the normal out-of the window scan.


44 of 97

Figure 5: Ex. of Navigation Display, with indication of the position of other a/c on taxiways. [Picture taken from Airbus FAST magazine No. 47 Automatic Dependent Surveillance Broadcast (ADS-B)

https://w3.airbus.com/CRS/A233_GN60/Customer_Services/html/acrobat/fast47_ADS_B.pdf]

The additional information on surrounding traffic consists of aircraft orientation and the relative information from aircraft in vicinity which are displayed on the Navigation Display (ND). Additional information can be accessed on the MCDUs (Multi-purpose Control and Display Unit) when selecting specific pages, such as a traffic list of aircraft with the following parameters: aircraft identification (callsign), bearing/distance, heading, wake vortex category, relative and absolute altitude, ground speed. With two traffic selector knobs the flight crew can interact with the Navigation Display symbols.

Pilots are not supposed to spend effort on finding the information anymore but rather checking and matching the information from different sources (out-of-the-window and displays). Under conditions of reduced or bad visibility, pilots have means to localise surrounding aircraft more easily and more reliable and can be more vigilant to do the correlation between visual scan and display information.

Design Implications

Based on the analysis of ATSAW SURF, the function supports mainly the cognitive tasks of searching and analysing information which relieves the flight crew and allows them to focus on the task execution as such. ATSAW SURF supports pilot’s monitoring (information acquisition) of parameters of aircraft in surroundings by providing aircraft navigation on the surface, in addition to airport information (maps, buildings, gates, etc.).

With all this potential amount of information present on an airport surface, cluttering on the display has to be avoided. Therefore, a display filtering logic has been developed in accordance with TCAS priorities and filters, and ND display priorities. For ATSAW SURF this filtering is based on displayed runways and proximity of other traffic on the ground to the ownship. Based on proximity and relevancy, e.g. a surrounding a/c under a Resolution Advisory is considered being more prior than another. To display a useful relevant amount of airport surface information, the maximum number of surrounding a/c displayed is limited to 8 + 1 (selected traffic by flight crew).

This display filtering capability can be classified as automation support on AL A5, since the applied criteria are relevant and solid enough. The filtering rules are transparent and predefined at design level. Hence, there is no specific need to explain in detail to the flight crew the underlying filtering rules or to train on them.

Available REOAs

ATSAW SURF (Annex A – Section 4.1.4)


45 of 97

External References

ATSAW SURF

o Cristal study: http://www.eurocontrol.int/cascade/gallery/content/public/documents/CRISTAL-ATSAW%20Final%20Report.pdf

o Airbus Fast Magazine No. 47 Automatic Dependent Surveillance Broadcast (ADS-B) https://w3.airbus.com/CRS/A233_GN60/Customer_Services/html/acrobat/fast47_ADS_B.pdf

o Getting to grips with Surveillance: http://www.cockpitseeker.com/wp-content/uploads/A320/pdf/data/gettingToGripsSurveillanceIssue1.pdf

o CASCADE Operational Focus Group: Use of ADS-B for Enhanced Traffic Situational Awareness on the Airport Surface (ATSA-SURF): http://www.eurocontrol.int/cascade/gallery/content/public/documents/ATSA-SURF%20ATC%20Info%20Leaflet%20V1.0%2016%20Nov%2009%20for%20Release.pdf





IAC-2: RELEVANCE AND AMOUNT OF INFORMATION

Present to the user only essential information to perform the task and minimize the amount of information which is useless for the purposes of the task

EXPLANATION

The HMI of the automated function should not present information which is irrelevant or rarely needed by the user. In a “dialogue” between the human and the automation every extra unit of information competes with the relevant units of information and diminishes their relative visibility. Of course defining which information is relevant will strongly depend on an adequate understanding of the activity that the user is performing by means of the automation in its different stages. Furthermore the determination of the adequate amount of information will also depend on the choice of the automation level in a given operational environment (see IAC-1). However the two following general criteria should always be considered:

The HMI should not present data which are useful to the system developer (e.g. software variables or configuration parameters) but not relevant for the end user tasks.

The information should be presented in a format which is meaningful for the end user and which facilitates the recovery of the relevant expert knowledge from the user long term memory.

For more specific guidance on this topic, please refer to the Generic SESAR Information Presentation Guide Project issued by the SESAR P16.5.3 (Guidance for an Effective Information Presentation).

http://www.cockpitseeker.com/wp-content/uploads/A320/pdf/data/gettingToGripsSurveillanceIssue1.pdf

http://www.cockpitseeker.com/wp-content/uploads/A320/pdf/data/gettingToGripsSurveillanceIssue1.pdf

http://www.eurocontrol.int/cascade/gallery/content/public/documents/ATSA-SURF%20ATC%20Info%20Leaflet%20V1.0%2016%20Nov%2009%20for%20Release.pdf

http://www.eurocontrol.int/cascade/gallery/content/public/documents/ATSA-SURF%20ATC%20Info%20Leaflet%20V1.0%2016%20Nov%2009%20for%20Release.pdf


46 of 97


Ground Default track label vs extended track label on CWPs


Default Track Label vs Extended Track Label on CWPs

A typical example of application of this principle is the design of the track label features on the HMI of state of the art controller working positions. Based on a widely recognized criterion, the design of track labels provides to the user (in this case the ATCO) the possibility to display different amounts of information for each track, depending on specific operational needs. Normally there is a default label configuration which includes a basic set of information that should be always visible to the controller. In the example depicted in the picture, the essential information items are: the Call-sign, the Actual Flight Level, the next Instructed Fix and the Exit Flight Level. Additional information items would be useful in some cases, but they are considered too many in normal conditions, due to the problem of cluttering with the other tracks and track labels. However, by way of a simple mouse-over, it is possible to extend the label and quickly display additional information for a specific track.

In the example highlighted in the picture, it is possible to spot three additional information items: the last Instructed Flight Level (in this case “340”), the next sector to which the flight is directed (in this case “SU2”) and an indication that the flight is performing a “Tactical Parallel Offset” manoeuvre (TPO) at 5 miles to the left with respect to centreline of the airway.

Figure 6: Example of basic and extended configuration of the track label

The TPO is a new operational concept currently being tested in a SESAR primary project (i.e. P4.7.3 – “Use of Performance Based Navigation for En Route Separation Purposes”). In the HMI setting currently investigated the controller can see if the flight has been authorized to perform one of these special manoeuvres thanks to an orange dot which distinguishes the specific track from the others. However, if s/he wants additional information on the manoeuvre, s/he can extend the label with a simple mouse-over.

This is just one possible example of track label design. Other examples are based on even greater differences in the amount of information included in the basic and extended configurations. Furthermore some implementations allow the ATCO to configure their own labels, by deciding how many ‘lines’ of information should be displayed as a default and how many in the extended configuration. The common criterion, however, is avoiding that controllers are overwhelmed with information items they normally don’t need and would be

Extended Configuration

Default

configuration


47 of 97

happy to visualize only in specific circumstances.

Available REOAs

Not available

External References

Default Track Label vs Extended Track Label on CWPs

SESAR 4.7.3 – “Use of Performance Based Navigation for En Route Separation Purposes” - Validation Exercise 1 Report (EXE-194)

https://extranet.sesarju.eu/WP_04/Project_04.07.03/Project%20Plan/Forms/AllItems.aspx




16) Poor usability of HMI may reduce the human performance benefits expected from the automation support


18) New automation support that results in greater use in visual information may lead to visual channel overload, with decrease in situation awareness and performance efficiency

IAC-3: AWARENESS OF SYSTEM LIMITATIONS

In case the information acquisition function does not have the capability to present operationally relevant information items, the user should be made aware of this limitation with appropriate HMI design solutions.

EXPLANATION

If an automated function supporting information acquisition ceases to work properly for a significant amount of time, due to technical limitations or failures (e.g. lack of essential source data), it is necessary that the user is made aware of the problem. If not properly notified or alerted, the user may start analysing the situation, selecting decisions and performing actions based on erroneous data. On the other hand if a relevant information item suddenly disappears as a consequence of a failure, the user may experience serious difficulties in understanding the situation or, even worse, s/he may formulate action plans completely disregarding an essential piece of information. Therefore, as far as technically feasible, a failure of an information analysis function to visualize or make available a certain information item should be managed by retaining for a certain time at least part of the information, whilst clearly showing that it cannot be considered reliable anymore. For example, for data visualized on a user display, the concerned information item should be represent with a symbology that clearly differentiates it from the other information that are still based on reliable data.


http://extranetarchive.sesarju.loc/WP_04/Project_04.07.03/Project%20Plan/Forms/AllItems.aspx


48 of 97

Ground TTW (Track Termination Warning) (not in REOAs)


TTW (Track Termination Warning)

The Track Termination Warning is a function of the ATM system proposed by NAV Portugal as part of the EUROCONTROL FASTI programme (First ATC Support Tools Implementation). The scope of this function is to highlight with a specific symbology those tracks for which the radar signals have been temporarily interrupted and whose position and altitude are being predicted and displayed based on the previously received radar and flight plan data. This problem may occur for different technical reasons, including inadequate radar coverage in specific areas or transponder failure. In such cases the TTW shows the concerned track with a wider circular symbol and with a highlighted label which can be clearly distinguished from the others. In this way the controller is aware that the calculated position of the track might be inaccurate and that the information included in the label is not updated until the system will receive the required data again. The associated pop-up window displays the time at which the correct transmission and integration of data was interrupted.

Figure 7: The Track Termination Warning.

Design Implications

The TTW proposed by NAV Portugal is only one example of ATM function managing the problem of the so-called lost tracks. Other ATM products adopt similar solutions for the same objective. However, the common element is the support offered to information acquisition also in case of a sudden loss of data which can severely affect the safety of operations. A specific symbology advises the controller that the associated a/c cannot be managed as all the other a/c for which reliable data are actually available. Therefore countermeasures and contingency procedures can be activated to mitigate the risk of undetected conflicts and to ensure at least a basic control service, until a complete data recovery is achieved.

Available REOAs

Not available

External References


49 of 97

Track Termination Warning

NAV Portugal Update on FASTI tools deployment - Jose Vermelhudo, Head Systems and Support

http://www.eurocontrol.int/fasti/public/standard_page/Workshop_Nov_2011.html


19) Lack of awareness of modes of operation may reduce efficiency and increase the risk of human error.

21) Lack of trust in automation may induce misuse, disuse or abuse of automation

22) Excessive trust in monitoring automation support may lead to complacency and reduced situation awareness.

5.2 Design Principles for information analysis functions (IAN)

IAN-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation support for information analysis tools when the automated function does not have the capability to compute relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for information analysis tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.

This design principle is divided in 3 different sub-principles, referring to different groups of automation levels: IAN-1.1 and IAN-1.2.

IAN 1.1: Choice of Automation Levels B2-B3

The AL B2-B3 functions provide the results of information analysis only on user request. These functions should be preferred when:

- there is no operational need for a systematic analysis of the concerned information or

- the internal logic of the automated function is not capable of processing relevant operational constraints and/or dynamic elements of the concerned operational environment, which may cause the automated function to activate when it is operationally inappropriate, thus causing disturbance and or excessive workload to the human operator

EXPLANATION

Compared to higher levels, the B2-B3 levels of information analysis support (IAS) require a higher cognitive load to the human operator. In fact, for each specific analysis regarding the status of the process being followed, the decision on whether and when there is a need for an automated support is completely up to the human.

At AL B2 the user can ask at any time the support of the automated function to perform the analysis of a certain set of information items. The result of the analysis will be then presented to the user in a

http://www.eurocontrol.int/fasti/gallery/content/public/Presentations/nov_2011/Day1-NavPortugal.pps

http://www.eurocontrol.int/fasti/public/standard_page/Workshop_Nov_2011.html


50 of 97

form that will not interfere with other parallel tasks that the user might be performing. It is up to the human operator to decide whether to retrieve the concerned result or not and to use it for the following decision and action selection.

At AL B3 the user can ask at any time the support of the automated function to perform the analysis of a certain set of information items. If the result of the analysis is considered operationally relevant the automated function will trigger a visual and/or aural alert to attract the user’s attention and reduce the possibility that the user will not notice it, in case s/he is busy in other parallel tasks.

On the one hand the higher level of cognitive load of the human operator required by these ALs may negatively impact the precision and speed of information analysis, leaving room to potential errors or omissions, especially in stressful situations. Changing operational conditions potentially dangerous for safety may remain unnoticed or may be detected too late for an adequate reaction in the following decision and action selection and action implementation stages. On the other hand the possibility for the human to decide whether and when a support by the automation is required (no automatic activation) will reduce the risk that the automated function will trigger nuisance alerts, potentially interfering with the execution of other parallel tasks. Triggering nuisance alerts may happen if the automated function is unable to detect and process operationally relevant constraints and changes that are essential to determine if a situation is actually dangerous and requires immediate attention by the user.

In such cases obliging the human to focus her/his attention on all the alerts (including the nuisance ones) may lead to desensitize the user to true alerts and cause mistrust in the automation itself. This may lead to losing the benefit expected from the automation or even reducing the ability of the user to manage the activities in a safe and efficient manner.

At design level it is preferable to choose these ALs when there is no operational need for a systematic analysis of the concerned information (e.g. in case of low traffic levels) or when it is considered too difficult or not cost-efficient to design the internal logic of the automation in a way that nuisance alerts will be reduced to an effective minimum.


Ground ERATO Filtering and What-if functions

Airborne - ATSAW ITP

- BTV RWY Exit Selection

ERATO Filtering and What-If Functions AL B3

The ERATO Filtering and what-if functions are specific functions of the ERATO (En Route Air Traffic Organizer) system offering to ATCOs the possibility to anticipate the identification of potential conflicts in the medium short-term (up to 20 minutes to the conflict).


51 of 97

Figure 8: Ex. of ‘ERATO filtering’ highlighting potential intruders of a specific flight.

The first function highlights potential intruders of a reference flight before any level or route change is applied. While the second function helps to spot potential conflicts before issuing a clearance implying some level or route change. Both the Planning and Executive Controller can activate these functions on request.

In practice, after mouse click on the concerned track, the filtering function supports a quick analysis of the flight in traffic context to timely detect possible conflicts and to identify appropriate resolutions (see Figure 8).

The What-if function uses the same logic but applied to simulated values. In the example depicted in Figure 9 a new flight level or a new routing.

Figure 9: Ex. of ‘ERATO What-If’ used to plan a re-routing.

Design Implications

As mentioned before these functions can be activated on request (i.e. at AL B3). Their visual alerts are not triggered automatically and leave full initiative to ATCOs on how to organize the strategy for ensuring separation. Compared to other information analysis tool, they offer less protection in term of conflict detection, but they are less subject to the negative consequences of potential nuisance alerts.

Also in situations in which a good quality of trajectory prediction cannot be ensured, such as in complex airspaces characterized by a considerable number of ascending and descending flights, they


52 of 97

don’t cause disturbance to the ATCO with an excessive increase of workload.

ATSAW In Trail Procedure (ITP) AL B2

ATSAW is an onboard application to improve situational awareness by providing information about surrounding aircraft using Automatic Dependent Surveillance-Broadcast (ADS-B) position reporting. Via ADS-B an information exchange between aircraft is enabled; hence the flight crew obtains enhanced information about aircraft in vicinity. In cruise and in oceanic airspace, ATSAW ITP enables the flight crew to change flight levels more frequently to reach optimum flight levels or to exit areas of turbulence. This enhancement can allow on board surveillance by flight crew to determine if optimum flight levels can be reached.

Based on calculations the function indicates if and when a FL change is possible based on the ADS-B information from the aircraft in vicinity. The algorithm of the function calculates the speed of rapprochement, the spacing and also considers the speed of the execution of the FL change manoeuvre.

Figure 10: Example of ATSAW ITP indications displayed on the cockpit. [Pictures taken from Airbus Fast Magazine No. 47 Automatic Dependent Surveillance

Broadcast (ADS-B) https://w3.airbus.com/CRS/A233_GN60/Customer_Services/html/acrobat/fast47_ADS_B.pdf]

The function allows pilots to better plan for oceanic flight level changes. More flight level changes can be taken advantage of under a short period of reduced separation until the desired FL is reached. These flight level changes can give benefit towards favourable winds or decreased drag, thus saving fuel burnt resulting in significant cost savings. The function also increases flight safety by providing a more intuitive display of surrounding aircraft.

Design Implications

ATSAW ITP supports the information analysis to indicate the feasibility of a FL change, precisely if an ITP is possible or not. The underlying algorithm considers the current operational parameters (as described in the illustration above).

It is left to the flight crew to initiate the request for the calculation whenever useful. ATSAW ITP


53 of 97

calculates the possibility for a specific FL that the crew has entered. Once the automated function has terminated the analysis it displays the result whether ITP is possible or not. The display of the result turns into another colour. This kind of automation support for information analysis can be classified as AL B2.

In case the requested FL change turns out to be feasible after ATSAW ITP calculation, pilots ask ATC to authorise this FL change (possible by means of CPDLC). So the execution (action implementation) of the FL change remains up to the flight crew.

In case an ITP is not possible, the flight crew may either wait (until ITP is indicated being possible) or launch a new query to ATSAW ITP with an alternative desired FL.

Despite the low level of automation of this function, the possibility for the crew to pre-calculate a possible FL change before addressing the request to the ATC via CPDLC is a definite improvement in terms of efficiency. As a matter of fact, the preventive exclusion of non-feasible FL changes saves time and optimizes air-ground communication. The combined use of data-link to request a feasible pre-calculated FL to ATC can allow saving a considerable amount of time compared to nowadays radio communications which can take several minutes over oceanic airspace.

Brake To Vacate - Runway Exit Selection AL B2

BTV is an enhancement of the classical auto-brake system at landing. It allows pilots to select the runway exit they can reach, by visually indicating to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The enhanced auto-brake system allows the aircraft to optimally reach the designated runway exit. The auto-brake activates roughly at the moment when the nose landing gear are down. The system guarantees the aircraft to vacate at the assigned exit with optimization of the brake energy regarding current operational constraints (weather, runway conditions), with minimization of the runway occupancy, and improvement of the passenger comfort. BTV allows pilots to select the runway exit they desire following these information and they can communicate to ATC.

Design Implications

To help the exit selection chosen by the pilot, the BTV system proposes a dedicated interface providing intuitive information to assist the selection of an optimum exit. This corresponds to Information Analysis cognitive function to a level at B2. It is not an AL higher than B2 because the selection of the ‘optimum’ exit remains the pilot’s responsibility (the system helps the human in analysing information only) and is not a contractual information between flight crew and controllers. These indications help the crew on the optimal thrust reversers’ usage strategy during the landing roll on dry runway.

Figure 11: Example of a BTV interface for a landing at CDG.


54 of 97

[Picture taken from Airbus FAST magazine No. 44 Brake-to-Vacate system: The smart automatic braking system for enhanced surface operations http://www.airbus.com/support/publications/]

When they select the runway for landing, BTV function estimates and shows the minimum braking distance in case the runway is dry and wet. This distance is symbolized with a bar meaning the point from where the aircraft will be able to stop. The pilots can then chose a runway exit located after the bar (according to dry or wet conditions).

The minimum braking distance representation support pilots for analysing (AL B2) if they can reach a certain exit or not (to arrive closer to the gate for example) and in a second step to decide which runway exit they want to use.

Available REOAs

ERATO Filtering and What-if functions (Annex A – Section 4.2.10)

ATSAW In Trail Procedure (Annex A – Section 4.1.3)

BTV RWY Exit Selection (Annex A – Section 4.1.6)

External References

ATSAW In Trail Procedure

o Airbus Fast Magazine No. 44 Brake-to-Vacate system: The smart automatic braking system for enhanced surface operations http://www.airbus.com/support/publications/



12) Poorly designed automation may lead to simultaneous tasks competing for user attention or causing interruptions of high workload activities, reducing efficiency and increasing the risk of human error.


23) Inadequate trade-off between nuisance/false alerts and warning time may cause mistrust in automation and increase workload


The AL B4-B5 functions perform systematic information analysis and trigger automatic alerts as appropriate. These functions should be preferred when the two following conditions are met:

- for operational reasons the user should be informed as soon as possible of critical results of the information analysis

- the internal logic of the automated function has the capability to process the most relevant operational constraints and/or dynamic elements of the concerned operational environment with an impact on the performance of the function, thus reducing the risk of triggering nuisance alerts to an effective minimum.

EXPLANATION

http://www.airbus.com/support/publications/



55 of 97

Compared with lower levels, the B4-B5 levels of information analysis support (IAS) require a lower cognitive load to the human operator. In fact, the automation performs autonomously a systematic analysis of all the available information items regarding the process being followed which have been specified at design level and alert the human operator only if the result of the analysis requires attention by the user.

At AL B4 the automated function triggers alerts based on predefined parameters that can be manipulated by the user himself (e.g. higher or lower warning time before a predicted conflict).

At AL B5 the automated function triggers alerts based on predefined parameters that cannot be manipulated by the user.

On the one hand the lower level of cognitive load required by these ALs may positively impact the precision and speed of information analysis, reducing the risk of potential errors with negative effects on safety, especially in stressful situations. On the other hand the automatic triggering of all alerts will increase the risk that the automated function will trigger nuisance alerts, potentially interfering with the execution of other parallel tasks. This may happen if the automated function is unable to detect and process operationally relevant constraints and changes that are essential to determine if a situation is actually dangerous and requires immediate attention by the user.

In such cases obliging the human to focus her/his attention on all the alerts (including the nuisance ones) may lead to desensitize the user to true alerts and cause mistrust in the automation itself. This may lead to losing the benefit expected from the automation or even reducing the ability of the user to manage the activities in a safe and efficient manner.

At design level it is preferable to choose these ALs when the results of the information analysis made by the automation refer to very critical operational situations in terms of safety (e.g. imminent risk of traffic conflict) which may require an immediate assessment and action by the user. Furthermore these ALs should be preferred when it is considered feasible and cost-efficient to design the internal logic of the automation in a way that nuisance alerts will be reduced to an effective minimum.


Ground - FASTI MTCD and TCT (Not in REOAs)

- A-STCA

Airborne BTV ROW

FASTI MTCD and TCT AL B4

The FASTI MTCD (Medium Term Conflict Detection) – Conflict Detection Tool (CDT) is an example of information analysis tool providing the ATCOs with automatic indications of conflicts predicted in the medium term (typically up to 20 minutes to the conflict, but with possibility for the ATCO to tune this parameter). It is mainly intended for the Planning Controller to support an early and strategic management of conflicts, with the aim to reduce the number of conflicts to be managed at tactical level and to assist the Executive Controller in the management of those conflicts which cannot be managed at strategic level.

Every time a conflict is predicted in the defined time-threshold a numbered icon is presented in a dedicated Potential Problem Display (PPD) on a graph of time (minutes until closest point of approach) and predicted minimum separation (see Figure 12 below).


56 of 97

Figure 12: The PPD Display of MTCD.

The trajectories of the two conflicting a/c, with a highlight of the point of minimum separation, can then be shown on the main radar screen after clicking on the PPD. This feature is normally referred to as POF, i.e. Problem Oriented Flight Leg.

Figure 13: The visualization of the conflict on the main radar screen.

Furthermore the MTCD-CDT function is integrated with another function specifically addressed to the Executive Controller, i.e. the Tactical Controller Tool (TCT). In practice, depending on a time threshold adjustable by the controller, the conflict is displayed also to the Executive Controller main radar display. Based on considering that the Executive Controller has little time available to look at the PPD display, a red dot is also included in the track label, to make sure that the controller does not miss a conflict that could not be solved by the Planning controller and manage it sufficiently in advance to prevent the triggering of an STCA (Short Term Conflict Alert).


57 of 97

Figure 14: Example of conflict visualized on the Executive Controller main radar screen.

Design Implications

The above mentioned visual alerts are all triggered automatically and are not activated on controllers’ request. On the other hand the controllers can adjust the time threshold determining when an alert will be visualized also to the Executive Controller screen and not only to the Planning Controller. This corresponds to an automation support provided at an AL B4. In practise the Planning Controller might decide to disregard the alerts and the Executive Controller might decide not to visualize them on the main radar screen, but their activation cannot be avoided. Such characteristic ensures that relevant conflicts cannot go unnoticed even in case of distraction or underestimation of safety relevant situations by the controller. However it is important that the number of nuisance alerts is maintained below a tolerable threshold.

One of the main factors influencing the nuisance alert rate is the reliability of the Trajectory Prediction (TP). The more the TP is in line with the actual behaviour of flights, the less is the risk of triggering alerts which do not correspond to real conflicts. Nonetheless too complex operational environments may cause TP to be very challenging. For example airspace characterized by a high proportion of vertical evolutions and limited number of overflies are likely to produce an increased nuisance alert rate. In such cases a lower level of automation support may result more fit for the purpose.

A-STCA (Advanced STCA) AL B5

The STCA (Short Term Conflict Alert) STCA is a ground-based safety net, i.e. a functionality of the ATM system intended to assist the controller in preventing collisions between aircraft by generating, in a timely manner, an alert of a potential or actual infringement of standard separation minima.

Figure 15: Example of a generic STCA alert HMI.


58 of 97

This alert normally consists in highlighting in red colour on the radar screen the two tracks involved in a conflict and in providing information on the current separation between them. In some cases the visual alert can also be complemented by an aural alert. The basic STCA functioning is based on an algorithm applying a linear extrapolation from each flight track based on surveillance data to predict their trajectory up to a maximum of 2 minutes (but normally below 1 minute) and in detecting if the two trajectories are going to get closer and to achieve a separation from each other that is lower than the standard separation minima. Since the timely identification of a current or predicted separation minima by the controller is of paramount importance for safety, this automated function is normally designed based on parameters which cannot be suppressed nor manipulated by the user, in order to prevent that any true alert goes unnoticed or is triggered too late for the controller to react immediately with the necessary avoiding instruction. However the STCA, as for other ground-based safety nets, is subject to the well-known issue of nuisance alerts. Due to a variety of operational and technical reasons, the controllers may receive an excessive number of alerts that do not correspond to a real treat, thus leading to lack of trust in the automation or in a progressive desensitization to the alerts. Since the longer the prediction (normally called “look ahead time”), the higher the potential amount of nuisance alerts, it is a real challenge for the designers of this function to identify the most appropriate trade-off between nuisance alerts and anticipated warning time, while assuring that there are no missed alarms.

In the last years several attempts have been made to improve this functionality by integrating the basic parameters (i.e. the linear prediction in a defined look ahead time) with a number of other data sources, configuration features and parameters.

The A-STCA presented here consists in a functionality that integrates the surveillance data by way of trajectory prediction and ADD (Aircraft Derived Data). Such data include: selected altitude, vertical rate, track angle, true track angle, track angle rate and roll-angle. Furthermore the A-STCA uses a multi-hypothesis processing in an attempt to reduce the nuisance alerts in areas of predictable manoeuvres such as for example, but not limited to, aircrafts being sequenced for final approach.

Figure 16: Example of multi-hypothesis processing by A-STCA for flights in final approach.

The picture above shows an example of how the advanced STCA algorithm can take into account known operational constraints (e.g. the need for flights in final approach to perform lateral manoeuvres shortly before starting the final descent in a parallel approach) and apply different time parameters for different hypotheses of aircraft manoeuvres. In the specific case illustrated above the STCA apply a longer prediction (i.e. an anticipated warning time) for the most likely case in which the a/c will turn in the direction of the runway and a shorter prediction (i.e. later warning time) in the more unlike case that the aircraft will proceed in linear direction. In this way the automation continues to offer protection in both cases, but minimizes the number of nuisance alerts associated to a standard behaviour of the flight.

Design Implications

The STCA is an automated function providing alerts to the controllers based on parameters pre-defined at design level. The alerts are activated with no need for user activation and without any


59 of 97

possibility for the user to configure or manipulate the underlying rule set. This corresponds to an AL B5, which guarantees systematic protection by the automation and minimizes the risk that important conflicts will go unnoticed. On the other hand, in order to make the function fit for the purpose and acceptable by the user, there is a need to maintain the number of nuisance alerts below an acceptable threshold, without delaying too much the time of each alert before a separation minima infringement. The A-STCA presented above manages this trade-off by integrating the surveillance data with ADD data (i.e. directly transmitted by the a/c) and by incorporating in the STCA logic relevant operational constraints which improve the quality of trajectory prediction. Other technical solutions aiming at the same purpose can be found in the dedicated EUROCONTROL Guidance Material (http://www.eurocontrol.int/safety-nets/public/standard_page/stca_02.html).

Brake To Vacate - Runway Overrun Warning (ROW) AL B5

BTV (Brake-To-Vacate) is an enhancement of the classical auto-brake system at landing. The system guarantees the aircraft to vacate at the assigned exit with optimization of the braking energy regarding current operational constraints (weather, runway conditions). BTV allows pilots to select the runway exit they desire following these information and they can communicate to ATC. BTV visually indicates to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The enhanced auto-brake system allows the aircraft to optimally reach the designated runway exit. The auto-brake activates roughly at the moment when the nose landing gear are down, with minimization of the runway occupancy, and improvement of the passenger comfort.

The objective of BTV coupled to the Runway Overrun Prevention and Warning System (ROW/ROP) is to prevent the runway excursion risk at landing. Pilots’ estimation of the aircraft touch-down may be approximate, as it does not result from precise calculation. The ROW/ROP based on BTV is able to give this precise information thanks to the considerations of the airborne progress and the airport databases.

Figure 17: Triggering conditions of BTV ROW/ROP function.

ROW is an alert which triggers when the aircraft is in flight, indicating visually (on Airport Moving Map, and Primary Flight Display PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. In general, when this alert triggers, it is impossible for pilots to appropriately adjust approach parameters to recover the situation, then, the procedure applied is a go around.

To illustrate the figure above, ROP is an alert which triggers when the aircraft touches down, indicating visually (on Airport Moving Map, and PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. The ROP may generally not trigger because the ROW should trigger before, but it may happen that the runway conditions are wrongly estimated and the ROP triggers the same alarm. Moreover, the ROP function associates also the auto-brake system to the alarm. This one activates automatically the maximum braking at the aircraft touch-down.

Design Implications

Considering the BTV ROW function, this kind of automation support can be classified as automation level B5. BTV ROW triggers an alert during approach in case the system detects that the aircraft will be unable to stop before the runway limit and risks to overrun it. The function does not only make data

http://www.eurocontrol.int/safety-nets/public/standard_page/stca_02.html


60 of 97

available for pilots (in order to analyse the situation) but analyses data and presents the results to the pilot (warning alert). The function is based on pre-defined and dynamic parameters in flight and at touch-down (weather conditions for example). In distinction of decision and action support, it is important to emphasise that BTV ROW only provides information but does not generate options or action possibilities as such. Pilots have to decide on the appropriate action following such alert (e.g. perform a go-around) still remaining in charge as decision-maker.

Available REOAs

A-STCA (Annex A – Section 4.2.2)

BTV ROW/ROP (Annex A – Section 4.1.7)

External References

EUROCONTROL MTCD-CDT and TCT

http://www.eurocontrol.int/fasti/public/site_preferences/display_library_list_public.html

http://www.eurocontrol.int/fasti/gallery/content/public/Documents/FASTI%20ATC%20Manual%20editio

n%201.0%20released%20issue.pdf

http://www.eurocontrol.int/fasti/gallery/content/public/awareness/index_standalone.html

A-STCA

http://www.skyguide.ch/fileadmin/user_upload/publications/safety-bulletins/Safety_bulletin_25_march2009.pdf

BTV ROW/ROP

Airbus FAST Magazine #44 / December 2009: http://www.airbus.com/support/publications/




23) Inadequate trade-off between nuisance/false alerts and warning time may cause mistrust in automation and increase workload

IAN-2: DEPENDENCY FROM USER INPUT

Minimize the dependency of information analysis tools from user input or keep the required human input to an effective minimum

EXPLANATION

Some automated functions supporting information analysis require manual inputs or updates by the user to work properly. This is for example the case of some controlling tools based on trajectory prediction that require the controller to timely update the a/c flight plans on track labels every time a change is instructed. The updates allow the system to make more accurate calculations of possible conflicts or deviations.

However when the demand on the user exceeds what is feasible or bearable, the updates may not


http://www.eurocontrol.int/fasti/gallery/content/public/Documents/FASTI%20ATC%20Manual%20edition%201.0%20released%20issue.pdf







61 of 97

arrive in due time, resulting in a bad performance or lack of support by the automation. In such cases the user will be running after the system with a reduced benefit or even a negative effect on safety and efficiency. While if it is less demanding to update the system, the controller has more opportunities to receive accurate indications and therefore to take full advantage of the system support.

Depending on the automation level, the impact of this design principle is different. At AL B2 and B3 (triggering information analysis on user’s request) the consequences of an excessive demand on the user might be less severe, since the controller is not receiving automatic alerts/advisories which may be nuisances. S/he can require assistance to the automation again as soon as s/he has the necessary cognitive resources available to update the system again. At AL B4 and B5 (triggering automatic alerts/advisories not based on user’s request) there is a risk that the controller will experience high workload conditions and disturbances from nuisance alerts.


Ground

- FASTI MTCD and TCT (Medium Term Conflict Detection and Tactical Controller Tool)

- CATO ECS (Executive Conflict Search)

- CATO FPM (Flight Path Monitoring

- ERATO (En Route Air Traffic Organizer) Monitoring Function

Airborne Not available.

FASTI MTCD and TCT – CATO ECS CATO Flight Path Monitoring Function - ERATO Monitoring Function

The 4 functions above are all presented together as examples related to this design principle, since they are all characterized by the need to rely on a good trajectory prediction. The first two are conflict detection tools, while the third and fourth ones are monitoring tools, to advise if an aircraft is deviating from its planned trajectory (note that a monitoring advisory tool also exist in the FASTI suite, although it is not investigated here).

The two images in Figure 18 show respectively an example of MTCD alert and ECS alert.

Figure 18: An example of MTCD alert on the left side and of ECS warning on the right side.

These alerts advise the controller that, if continuing in this trajectory, a missed separation (i.e. an infringement of standard separation minima) will occur in a given time threshold (the prediction is normally made up to 20 minutes to a separation infringement). In case a change of the planned flight route is authorized by the controller but not correctly input onto the corresponding track label, there is a risk that the tool will trigger alerts which do not correspond to a real threat, due to the erroneous trajectory prediction computed by the system.


62 of 97

While the four images in Figure 19 and Figure 20 show different kinds of monitoring advisories, indicating that an aircraft is deviating from the cleared trajectory either on the horizontal or vertical plane.

Figure 19: Examples of ECS Flight Path Monitoring alerts for FL deviation on the left side and

for cleared route deviation on the right side.

Figure 20: Examples of ERATO Monitoring function alerts, for horizontal deviation on the left

side and for vertical deviation on the right side.

In this case, if a change of the planned flight route is authorized by the controller but not correctly input onto the corresponding track label, there is a risk that the tool will advise a deviation from the flight plan which does not correspond to reality, due to the underlying erroneous prediction.

Design Implications

It is worth noting that for a conflict detection tool an alert or advisory which is generated due to a lack of trajectory update by the controller will be simply a nuisance and when the number of nuisances is excessive there is an obvious negative effect on the controller’s performance. While for the monitoring advisory tools an alert caused by a lack of trajectory update (normally less critical than an alert indicating a conflict) may also be a useful remainder for the controller of the need to update the trajectory itself. Despite this potential double use of the alert can be considered an advantage, an excessive number of alerts not caused by an actual trajectory deviation is a symptom that the controller is running after the automation and again not taking full benefit from it.

To manage this issue in a effective manner for both conflict detection and monitoring advisory tools at least 3 conditions should be met:

- controller’s working methods should include systematic updates of trajectory related data into the CWP HMI even when controller-pilot communication is still entirely based on R/T communication (e.g. “update the system as you speak”).

- the usability of input devices (e.g. drop down menu features) should be adequate to facilitate a quick and easy update of either the routing and/or flight level.

- the automated function should be introduced in an operational environment in which timely and systematic updates of trajectory by the controller should be practically feasible.

Available REOAs

CATO ECS (Annex A – Section 4.2.4)

CATO FPM (Annex A – Section 4.2.5)

ERATO Monitoring Function (Annex A – Section 4.2.11)

External References


63 of 97

EUROCONTROL MTCD-CDT


http://www.eurocontrol.int/fasti/gallery/content/public/Documents/FASTI%20ATC%20Manual%20editi

on%201.0%20released%20issue.pdf




11) Automation could require additional system inputs, which may lead to increased task load and reduced acceptance


IAN-3: SUPPRESSION OF ALERTS

If the triggering of automatic information analysis alerts (AL B4 and B5) can be suppressed by the user, then make evident on the HMI that the alerting has been inhibited and define clear criteria establishing if and when the automatic alerts should be re-activated

EXPLANATION

As highlighted in IAN 1.2 the automated functions at AL B4 and B5 which support information analysis in a systematic way and trigger automatic alerts with no need for human activation should be preferred in case of operational situations that are critical for safety. However also for these functions there might be a need to handle exceptions which are too difficult to manage at design level and that will inevitably cause alerts considered unnecessary by the user. In such cases, and when it is assumed that the nuisance alerts will remain an exception (i.e. when the number of their occurrences will remain limited and easily recognizable by the user), it is an accepted practice to allow the manual suppression of individual alerts by the user.

The suppression of alerts might be either preventive - i.e. applied before the alert is triggered – or applied after a specific alerts has been triggered. In the first case the suppression is commonly defined inhibition or de-activation, while in the second case it is commonly defined acknowledgment. In both cases it is essential that the HMI somehow advice the user that the usual alerting capability has been suppressed and, to the extent possible, such advice should be provided as close as possible to the physical location were the alert can normally be activated.

Furthermore the procedures associated to the concerned function should clearly indicated when the user is allowed to suppress the alerts and if/when the alert can be re-activated after a previous suppression.


Ground MSAW (Minimum Safe Altitude Warning) (Not in REOAS)






64 of 97


MSAW (Minimum Safe Altitude Warning) with alert inhibition feature

The MSAW is a ground-based safety net intended to warn the controller about increased risk of controlled flight into terrain accidents by generating, in a timely manner, an alert of aircraft proximity to terrain or obstacles. This alert normally consists of highlighting in red colour on the radar screen part of the track label associated to a flight which is flying (or going to fly) below a previously established altitude and/or in displaying on the label an “MSAW” message (see the example in the picture below). In some cases the visual alert can also be complemented by an aural alert.

Figure 21: An example of visual MSAW alert.

[Picture taken from a EUROCONTROL case study report concerning MSAW and conducted in collaboration with Skyguide http://www.eurocontrol.int/safety-nets/gallery/content/public/gm/gmD-

2_FhaMSAW-10.pdf]

Since the timely identification of a current or predicted separation minima by the controller is of paramount importance for safety, this automated function is normally designed based on parameters which cannot be suppressed nor manipulated by the user (i.e. at AL B5), in order to prevent that any true alert goes unnoticed or is triggered too late for the controller to react immediately with the necessary avoiding instruction. However there might be operational situations in which there is a need to handle exceptions which are too difficult to manage at design level and that will inevitably cause alerts considered unnecessary by the user.

In some ACC and APP centres, for example, the same sector of the airspace can be flown by both IFR flight which are receiving full control service by the ATCOs and small number of VFR aircraft which may come from touristic aerodromes in the vicinity and may be intentionally flying in close proximity to terrain to maintain visual references. In these cases the controllers should immediately provide climb instructions in case of IFR aircraft flying below an agreed altitude and just disregard the VFR flights which are not under their responsibility. Managing this difference with the same alerting logic and eligibility rules may not be easy, especially in borderline situations, such as flights with an IFR-related flight plan which initially climb as VFR or flights with an SSR code indicating an IFR status which are then authorized to perform a VFR approach. In some control centres characterized by this situation, the ATCOs are allowed to either inhibit or acknowledge an MSAW alert when the concerned flight is explicitly notified to be VFR and therefore not under their control.

The example illustrated in the previous picture actually shows an MSAW system which is normally based on both a visual alert and an aural alert. However in limited and well defined cases the ATCOs are allowed to de-activate the alerting associated to specific tracks. Once the alerting is suppressed the aural alerting is suppressed as well as the visual indication “MSAW”. However the FL which is normally displayed in green is displayed in red, to show that the specific track is not protected by any MSAW alerting in case the flight will go below the agreed minimum safe altitude (see Figure 22).

http://www.eurocontrol.int/safety-nets/gallery/content/public/gm/gmD-2_FhaMSAW-10.pdf



65 of 97

Figure 22: An example of track with visual MSAW alert de-activated

Design Implications

The example illustrated above shows how it is possible to reduce the potential disturbance caused by unnecessary alerts by allowing a manual suppression by the controller (normal MSAW alert not visualized and no aural alert triggered), but still facilitating the user in keeping track of the fact that the automation has been inhibited. Note that the alerting performance will of course continue to work for all the other tracks. On the other hand the tracks whose MSAW alerting has been either de-activated or acknowledged will not trigger any new alert, unless not deliberately decided by the controller.

Available REOAs

Not Available

External References

MSAW





5.3 Design Principles for decision and action selection functions (DAS)

DAS-1: CHOICE OF AUTOMATION LEVEL

Prefer lower levels of automation support for decision and action selection tools when the automated function does not have the capability to compute some relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for decision and action selection tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.



66 of 97

This design principle is divided in 3 different sub-principles, referring to different groups of automation levels: DAS-1.1, DAS-1.2 and DAS-1.3.

DAS-1.1: Choice of Automation Levels C2-C3-C4

The AL C2-C3-C4 functions leave more than one decision alternatives to the human or do not allow any following action execution without human consensus. These functions should be preferred when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is based on a cooperation between the human operator and the automated function, maintaining the human fully in control of the situation.

EXPLANATION

Compared to higher levels, these levels of decision and action selection (DAS) require a higher cognitive load to the human operator but also leave a higher degree of freedom to decide how to manage the ongoing operational situation.

At AL C2 the operator is required to analyze and asses the different alternative options proposed by the automation and should also consider alternative options.

At AL C3 the available options are limited to those proposed by the system, but still there is a need that the human operator selects one of them and checks if it is appropriate to manage the ongoing operational situation.

Finally, at AL C4 the human is only required to check the validity of the unique option selected by the system. However the cooperation between the human and the automation is remarkably different if this level of automation is followed by an AIS level lower than D5. If the associated AIS level is lower than D5, no action execution will be implemented until the human decides to activate it. If the associated AIS level is at least D5, action execution will be implemented also without initiation by the human.

On the one hand the higher level of cognitive load of these ALs may negatively impact the precision and speed of decision and action selection, leaving room to potential errors, especially in stressful situations. On the other hand the higher degree of freedom allows the human to correct the automation in case of contextual changes or intervening variables which cannot be detected or managed by the automation itself. Without this human intervention the automation may execute actions in a way that compromises either the safety or the efficiency of operations.

In such cases preventing the human from having full control on the decisions may lead to either losing the benefits expected from automation or generating undesired side effects.

At design level it is preferable to choose these ALs when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. Safely, because some relevant operational constraints may compromise the safety of operation if disregarded by the automation. Efficiently, because it may be not cost-effective to design an automation with the capability to consider all the relevant operational constraints.


Ground - SARA (Speed and Route Advisor)

- TMA 2010+ Project South AMAN (Arrival Manager)


SARA (Speed and Route Advisor) AL C4


67 of 97

The objective of the SARA function is to give advice on speed and/or routing to (Upper) Area Controllers in order to achieve the planned arrival time(s) of the aircraft over or abeam fixes. Similarly to an AMAN function, SARA is expected to contribute to a more accurate delivery of traffic at the metering fixes (IAFs) causing less workload for the involved controllers. This should be achieved by overall reducing the number of tactical clearances (and thus the R/T load), thanks to the ability to generate a single, comprehensive, conflict-free solution to meet the time at the IAF.

The figure below presents an example of the track label, with the advisories for the controllers displayed in white colour in the upper part. Namely there is an indication of the suggested speed on the left side and of the preferred routing on the right side. The controllers are expected to read these indications and communicate them to the pilots when providing clearances and instructions.

Figure 23: An example of the SARA advisories in a track label.

Design Implications

Based on an analysis of the SARA HMI illustrated above, the support offered by the automation to the human performance can be classified as AL C4, followed by an AIS level D0. The function decides which is the action to be performed and communicates it to the controller. Then it is up to the controller to decide whether to apply the action or not.

Actually this kind of automation support is fit for the purpose if the complexity of the concerned airspace is limited, if fixed air routes are really applicable, if it is concretely possible to apply CDA (Continuous Descent Approach) and if reliable data concerning the different aircraft performances and the different airline procedures are actually available to the automation. When such conditions cannot be met, a strict following of the Speed and Route advisories may generate a flow of traffic which is not suitable for achieving the planned arrival times or which does not allow to comply with other relevant operational constraints, such as ensuring standard separation minima, taking into account the orography of the area or complying with individual airline procedures.

As a matter of fact this kind of automation support leaves full control on the action implementation to the user (the advisories have no concrete consequences if the controller does not communicate them to the flight crew and if the pilots do not execute them). However in terms of decision support the function does not allow flexibility to the ATCO, in case s/he realizes that the advisories cannot be strictly followed to cope with all the operational constraints. In such cases the only alternative is to ignore the indications provided by the automation and just revert to the original working method, not based on automation support.

On the other hand, if the complexity of the operational environment is limited and if the logic and parameters of the function take into account relevant features and constraints, such as those mentioned above, the work of the ATCO is radically simplified, since s/he just has to briefly assess the feasibility of the speed and route indication and communicate them to the pilots, with a considerable reduction of its workload.


68 of 97

TMA 2010+ Project South AMAN (Arrival Manager) AL C2 vs AL C4

The TMA 2010+ Project South was aimed at investigating the typical role of an AMAN function, i.e. to stabilize and make efficient and predictable the flow of inbound traffic in TMA areas. Such role is achieved by providing visual indications on the track label of the a/c which are under the control of upper area controllers, in sectors which are sometimes called E-TMA (Extended TMA) sectors. As for the SARA example above, the controller are supposed to use these advisories to provide appropriate clearance and instructions to the pilots.

However, one of the objectives of the project was also to test the feasibility of integrating the use of AMAN with the PMS (Point Merge System), a procedure intended to facilitate the merging of traffic from a number of arrival routes taking advantage of the P-RNAV (Precision Area Navigation) features of aircraft. In this respect AMAN calculations were not expected to meter traffic directly at each airport runway (i.e. at each IAF) as in the usual application of this tool. Rather the AMAN was required to ensure a smooth flow of traffic at the entry point of each PMS Triangle (see an example of PMS triangle in the figure below).

Figure 24: Graphical representation of a typical PMS procedure.

Organizing the flow of traffic at the entry points of the PMS, also named “Sequencing Legs”, implied specific working methods to be applied by the controller. For example the traffic entering the PMS needed to be at a minimum separation of 7NM. Plus the arrival traffic needed to enter at a predefined flight level and speed. And both the conditions needed to be reached at least 10 NM prior to the entrance into the sequencing leg. Therefore such working methods added additional constraints to those already considered into the AMAN parameters.

In the Real Time Simulations performed during the project, two different AMAN MHI designs were tested. The first one (called Basic AMAN) was based on “Time to Lose – Time to Gain” advisories concerning the delay measures needed to comply with the optimised sequence. As anticipated, the advisories were included in the track label of each aircraft and corresponded to a determined time to gain or lose, as indicated in the Table 12. In the pictures below two examples of advisories (LO and LL) are highlighted with a red circle on the upper left side of the label.

Table 12: The meaning of each advisory in the Basic AMAN.

HMI Indication Required Action

G (Gain) Gain 2 minutes or more

L0 (Lose 0) Lose fro from 0 to 2 minutes

L (Lose) Lose from 3 to 5 minutes

LL (Lose/Lose) Lose 6 minutes or more


69 of 97

Figure 25: Two examples of advisories used in the Basic AMAN HMI.

On the other hand, the second kind of HMI tested during one of the RTS (called Advanced AMAN) was on a higher level of automation. It included in the track label a precise indication of the desired ground speed (see the red circle in the upper left side of Figure 26) and of the “Top of Descent”, i.e. the precise time at which it is desirable that the a/c start its descent (see the red circle in the upper right side of Figure 26).

Figure 26: Two examples of advisories used in the Advanced AMAN HMI.

Design Implications

Although the two HMIs may appear quite similar, the kind of support they offer to the human performance is considerably different.

In the case of Basic AMAN the controller receives an indication of the trend that the aircraft should follow (e.g. losing or gaining a certain amount of time), but does not prescribe strictly the way to achieve this result (e.g. a similar effect can be achieved either by asking to the pilot a reduction of speed or by instructing an altitude change). Therefore when issuing instructions and clearances to pilots such indications can be taken into account by the ATCO, but can also be combined with other constraints, such as the need to comply with specific airline procedures pertaining to speed and fuel consumption or to consider the characteristics of the local ATS geography (for example in the ACC were the simulation was made, it was not always possible to apply a continuous descent approach manoeuvre, due to terrain altitude in some areas).

This kind of automation support can be classified as AL C2, because the user is free to choose between one or more options to follow the indications given by the automation and does not lose the entire benefit of the indications if s/he cannot fully comply with the advisory.

While in the case of Advanced AMAN the controller receives very precise indications which in practice should be communicated as such to the pilot without investigating on their motivation or trying to make them compatible with other constraints. For example the ATCO might not be aware if the speed s/he is instructing to the a/c will imply an increase or reduction of the current ground speed, unless s/he asks directly to the flight crew to notify the current ground speed. Therefore s/he may be uncertain on the actual consequences of this action on surrounding traffic, but s/he is obliged to either instruct it to flight crew or to ignore it. In addition the precise “Top of Descent” indication will be applicable only if the continuous descent approach can actually be implemented in the concerned airspace. While if local constraints require the aircraft to perform a staggered approach or if specific airline procedures do not allow flying at certain levels, the time indication will result invalid. In practice if the ATCO understands that the indication provided by the Advanced AMAN is inaccurate or not applicable based on local constraints, s/he can only disregard it, losing its entire expected benefit. This kind of automation support can be classified as AL C4, followed by an AIS level D0. The function decides which the action to be performed is and communicates it to the controller. Then it is up to the controller to decide whether to apply the action or not.

For the reasons explained above, during the RTS performed in the context of TMA2010+ Project


70 of 97

South, the Basic AMAN was deemed more fit for purpose than the Advanced AMAN (this was one of the results achieved in the context of evaluating the usability and acceptability of the tool with the controllers). The need to ensure interoperability between AMAN and PMS-related working methods, as well as the constraints of the specific operational environment (a very crowded TMA with an orography and an ATS geography not allowing full implementation of continuous descent approach) were better managed by ATCOs with the Basic AMAN, thanks to higher flexibility allowed by the lower level of automation.

Available REOAs

SARA (Annex A – Section 4.2.16)

TMA2010 + Project South AMAN + PMS (Annex A – Section 4.2.7)

External References

Not available





71 of 97

DAS-1.2: Choice of Automation Level C4 (with associated Action Implementation not lower than D5)

The specific case of AL C4 connected to a following automatic action implementation support (not lower than D5) should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is delegating them to the automated function, leaving to the human operator only the possibility to interrupt the following action implementation.

EXPLANATION

Compared to lower levels, the level of automation C4 followed by an AIS level not lower than D5 implies virtually no cognitive load by the human operator. The human is only informed of the option selected by the automation. All possible human interventions are postponed to the following action implementation phase.

On the one hand this lack of human intervention may positively impact the precision and speed of decision and action selection, reducing the risk for potential errors with negative effects on safety, especially in stressful situations. On the other hand the lack of intervention may prevent the human from fully remaining in the loop. All possibilities (if any) to correct or modify a possible negative course of action will be postponed after the automated execution has already started. Such interventions may turn out to be inadequate or too late in case of contextual changes or intervening variables which cannot be detected or managed by the automation itself.

At design level it is preferable to choose these ALs when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. Safely, because the most relevant operational constraints with an effect on safety are taken into consideration in the internal logic of the automation. Efficiently, because it is considered cost-effective to design an automation with the capability to consider all these operational constraints.

In this respect there is no remarkable difference between this AL and the higher levels C5 and C6.



Airborne BTV ROP (same example presented for AIS 1.2)

Brake To Vacate - Runway Overrun Protection AL C4 (followed by AL D6)

BTV (Brake-To-Vacate) is an enhancement of the classical auto-brake system at landing. It allows pilots to select the runway exit they can reach, by visually indicating to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The auto-brake activates roughly at the moment when the nose landing gear are down. The system guarantees the aircraft to vacate at the assigned exit with optimization of the brake energy regarding current operational constraints (weather, wet runway conditions, etc.), with minimization of the runway occupancy, and improvement of the passenger comfort.

The objective of BTV coupled to the Runway Overrun Prevention and Warning System (ROW/ROP) is to prevent the runway excursion risk at landing. Pilots’ estimation of the aircraft touch-down may be approximate as it does not result from precise calculation. The ROW/ROP based on BTV is able to give this precise information thanks to the considerations of the airborne progress and the airport databases.


72 of 97

Figure 27: Triggering conditions of BTV ROW/ROP function

ROW is an alert which triggers when the aircraft is in flight, indicating visually (on Airport Moving Map, and PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. In general, when this alert triggers, it is impossible for pilots to appropriately adjust approach parameters to recover the situation, then, the procedure applied is a go around.

ROP is an alert which triggers when the aircraft touches down, indicating visually (on Airport Moving Map, and PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. The ROP may generally not trigger because the ROW should trigger before, but it may happen that the runway conditions are wrongly estimated and the ROP triggers the same alarm. Moreover, the ROP function associates also the auto-brake system to the alarm. This one activates automatically the maximum braking at the aircraft touch-down.

Design Implications

The ROP function triggers an alert once the aircraft is on ground, in case the aircraft is unable to stop before the end of the runway. The system is able to assess the situation and decide to brake with maximum energy if the aircraft risks of overrunning the runway end. That is why the AL C4 is applicable to this system. The ROP is systematically accompanied with the maximum braking action of the aircraft. In this case AL C4 is followed by AL D6 because the system decides and initiates the action of braking. Pilots can override this automation only by interrupting the operation and taking over the aircraft control manually.

Generally, the ROP function should never trigger if pilots make a corrective action when the ROW triggers (the corrective action in flight is the landing avoidance with the go around). But, it may happen that the ROP triggers but not the ROW, in case, for example, the runway conditions have changed before touch-down. In this case, the maximum automatic braking activates automatically at the aircraft touch-down at the same time of the alert.

Available REOAs


External References

Not available



11) Automation could require additional system inputs, which may lead to increased task load and reduced acceptance.


73 of 97

DAS-1.3: Choice of Automation Levels C5-C6

The AL C5-C6 functions do not inform the human of the selected option or inform her/him only on request. These functions should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best way of generating decisions is delegating them to the automated function, leaving to the human operator only the possibility to interrupt the following action implementation.

EXPLANATION

Compared to lower levels of decision and action selection, these levels do virtually not imply cognitive load by the human operator. The human is not informed of the option selected by the automation (C6) or s/he is informed only on request (C5) and all possible human interventions are postponed to the following action implementation phase. On the one hand this lack of human intervention may positively impact the precision and speed of decision and action selection, reducing the risk for potential errors with negative effects on safety, especially in stressful situations. On the other hand the lack of intervention prevents the human from fully remaining in the loop. All possibilities (if any) to correct or modify a possible negative course of action will be postponed after the automated execution has already started. Such interventions may turn out to be inadequate or too late in case of contextual changes or intervening variables which cannot be detected or managed by the automation itself.

At design level it is preferable to choose these ALs when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. Safely, because the most relevant operational constraints with an effect on safety are taken into consideration in the internal logic of the automation. Efficiently, because it is considered cost-effective to design an automation with the capability to consider all these operational constraints.



Airborne BTV Auto-brake

Brake To Vacate – Auto-brake AL C6

BTV (Brake-To-Vacate) is an enhancement of the classical auto-brake system at landing. It allows pilots to select the runway exit they can reach, by visually indicating to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The enhanced auto-brake system allows the aircraft to optimally reach the designated runway exit. The auto-brake activates roughly at the moment when the nose landing gear are down. The system guarantees the aircraft to vacate at the assigned exit with optimization of the brake energy regarding current operational constraints (weather, wet runway conditions ...), with minimization of the runway occupancy, and improvement of the passenger comfort. BTV allows pilots to select the runway exit they desire following these information and they can communicate to ATC.

Despite BTV is an airborne system which is entirely dedicated to pilots’ use, the function may have impacts on ground domain, as it helps to better predict and ensure a runway exit. The ramp where the aircraft exits is the starting point of the taxi-in clearance given by the controller. Ground systems and actors would then be able to plan the aircraft movement if pilots can ensure to ATC the runway exit he is going to take after landing. Auto-brake of BTV may improve the whole surface routing and planning.

Enhanced auto-brake system with BTV allows the aircraft to brake optimally and without pilot’s action until a pre-selected runway exit.

The optimum braking application depends on the pre-selected exit, which depends itself on multiple


74 of 97

criteria and constraints that can only be known in their full complexity by the pilot and the ATCO:

-Optimum braking energy (complex as function of taxi, of requested Turn Around Time (TAT), of noise abatement procedures preventing maximal reverse thrust usage out of safety needs), - Minimum number of brake applications, - Minimum runway occupancy time, - Best exit for taxi duration.

Design Implications

Pilots have to activate BTV during approach for auto-brake activation. But, during the operation, the system decides and adjusts itself the braking energy considering the braking progress, runway conditions, point of touch-down, etc, to optimally and progressively reach the pre-selected exit. The AL C6 is considered because the system generate options and decides autonomously on the action to be performed (braking energy selection) without informing the human. Indeed, pilots are not aware of all the parameters and estimations made by the system when it brakes, they can monitor only the result of these calculation, represented by the braking itself.

Available REOAs

BTV Auto-brake (Annex A – Section 4.1.5)

External References

BTV Auto-brake




11) Automation could require additional system inputs, which may lead to increased task load and reduced acceptance.

DAS-2: AUTOMATION OVERRIDE

If the decision support by automation can be suppressed or overridden by the user, then define clear criteria or mechanisms for reactivation or reinsertion of the automation support.

EXPLANATION

The decision support automated functions, as well as other automated functions, are often complemented with features that allow the user to “suppress”, “freeze” or “acknowledge” the indication, advisory or alert given by the automation, when this is considered incorrect or useless. Such features are essential especially in complex operational environments, when it is too difficult to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In this cases there is a need for the human operator to handle a significant number of exceptions to the rule set the automation is using for decision and action selection. Nonetheless, the lack of clear criteria or mechanisms to define when the automation should show up again with its own indications may have negative consequences for both the efficiency and safety of operations. On the one hand an important part of the benefit given by the automation may be lost. On the other hand, especially if the human is used or trained to take advantage of the automation support, s/he may be mistakenly relying on a support which is not available anymore.



75 of 97

The guideline applies to all automation levels providing decision and action support to the user, based on some kind of cooperation between the automation and the human. These are AL C2-C3-C4 and with limitations C5-C6. The AL C2 and C3 are concerned, because the automated function is offering decision and action selection support, but the user has still to select the preferred option. The AL C4 is concerned because the user can always prevent the execution of an action s/he does not agree with. The same applies to C5 and C6, but only with limitations, since the user can be aware about automated actions only on request (C5), or can intervene only after an action has already started (note that when C5 is coupled with D8 there is no more cooperation but only replacement of the human by the automation).


Ground AMAN (TMA2010+ Project South)


AMAN (TMA2010+ Project South)

One component of the AMAN (Arrival Management) function which was tested during the real time simulations of the TMA2010+ Project South (see also DAS-1.1) provides an example of decision and action selection support tool in which a cooperation is established between user and automation, with possibilities for the user to override the indications by the automation. This component – called AMAN Master View – consists of a side display, separate from the main radar screen, showing in a timeline format the sequences of a/c arriving to the different runways, as proposed by AMAN. It is used by the Sequence Manager, a new type of controller which was introduced in the simulation to take care of the arrival sequence in the concerned TMA. Actually the Sequence Manager uses this functionality as an information source to ensure a correct balancing of the traffic load directed towards different runways, by both checking the evolution of traffic flows and providing voice indications to E-TMA (Extended TMA) and TMA controllers on the preferred controlling strategy.

In the AMAN Master View each aircraft is visualized with its call-sign, with the runway in which it is expected to land and with a progressive number indicating its position in the sequence (see Figure 28). In case the Sequence manager does not agree with the sequence proposed by AMAN, s/he can manipulate it by swapping the positions of individual a/c or even by cancelling some of them from the sequence (e.g. in case of emergencies an aircraft may take precedence over all the others in the sequence, hence making impossible for AMAN to calculate correctly its position in the sequence and requiring ATCOs to control it by completely disregarding AMAN indications).

Figure 28: The AMAN Master View Window.

Note that the AMAN Master View is connected to a second HMI component of the AMAN, which consists of the indications sent to the E-TMA controllers in the track label of each individual a/c (i.e.


76 of 97

the HMI component described in the previous DAS-1 guideline). These are the “Time to Lose – Time to Gain” (TTL-TTG) advisories displayed at the CWP of both the PC and EC of each E-TMA sector, as shown in the picture below (for the meaning of each advisory please refer to the Table 12 above in the context of DAS-1guideline).

Figure 29: Two examples of advisories used in the first AMAN HMI.

In practice the two HMI components interact between each other, since the TTL-TTG advisories are based on calculations by the system on how to reach the optimized sequence displayed onto the “AMAN Master View”. So every time there is an automatic update of the sequence or a manipulation of it by the Sequence Manager (e.g. it is decided that one a/c should precede another a/c which was previously before it in the sequence) there is an impact on the advisories. For example it is likely that the preceding a/c will receive a “G” on its track label and the following a/c an “L” or “LL”.

Design Implications

During one of the real time simulations performed in the context of TMA2010+ Project South an HP automation support issue was identified regarding the effectiveness of the cooperation between the Sequence Manager and the AMAN. Many cases were observed in which a manual change of the sequence was followed by an AMAN recalculation which restored the sequence order previously modified by the Sequence Manager. In practice although the Sequence Manager was operating changes in the sequence due to operational reasons not considered by AMAN, after a while AMAN was simply recalculating the sequence according to its own parameters. Since such behaviour of the automation also had effects on the advisories received by E-TMA controllers, the Sequence Manager was either obliged to restore again its preferred sequence or required to explain the unwanted change in R/T communications with E-TMA controllers, resulting in a clear loss of efficiency in the overall controlling activity.

To overcome such inconvenience the controllers attending the simulation proposed to introduce a Freeze Function allowing the ATCO to block small chains of a/c to maintain their position in the sequence as established by the Sequence Manager (e.g. 5 or 10 a/c in the sequence depending on specific operational needs), with the possibility to also unblock the chain later.

A freezing function was actually implemented in the system being tested during the simulation, but it could be only used to freeze the entire sequence starting from a selected a/c until the end of the sequence. Therefore ATCOs preferred not to use it to avoid loosing the entire benefit of AMAN. While the proposed selective freeze functionality was expected to foster a better cooperation between the human and the automation.

As a matter of fact the proposed solution allows the human to compensate for the limitation of the automated function, without causing disturbances to its direct and indirect users (i.e. in this case the Sequence Manager observing the sequence and the E-TMA controllers receiving the time advisories correlated to it). At the same time the full benefit of the automation support is maintained for the entire part of the sequence not being frozen.

Available REOAs

TMA2010 + Project South AMAN + PMS (Annex A – Section 4.2.7)

External References

Not available


77 of 97






5.4 Design Principles for action implementation support functions (AIS)

AIS-1: Choice of Automation Level

Prefer lower levels of automation support for action implementation tools when the automated function does not have the capability to compute relevant operational constraints and/or dynamic elements of the concerned operational environment.

Prefer higher levels of automation support for action implementation tools when the automated function has the capability to compute most of the relevant operational constraints and/or dynamic elements of the operational environment.

This design principle is divided in 3 different sub-principles, referring to different groups of automation levels: AIS-1.1, AIS-1.2 and AIS-1.3.

AIS-1.1: Choice of Automation Levels D2-D3-D4

The AL D2-D3-D4 functions perform action implementation only after human initiation. These functions should be preferred when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best strategy for action implementation is based on a cooperation between the human operator and the automated function, maintaining the human fully in control of the situation.

EXPLANATION

Compared to higher levels, these levels of action implementation support (AIS) provide a higher degree of freedom to the human operator.

At AL D2 the operator executes at least part of the action and/or receives feedback on the correctness of the execution by the automation. At AL D3 the operator decides when to activate and to interrupt the execution by the automation and can modify it manually while it is ongoing. Finally, at AL D4 the operator can only decide when to activate and interrupt the sequence.

On the one hand this higher degree of freedom may negatively impact the precision and speed of action implementation, leaving room to potential errors, especially in high workload and stressful situations. On the other hand the higher degree of freedom allows the human to correct or interrupt the automation in case of contextual changes or intervening variables which cannot be detected or managed by the


78 of 97

automation itself, but can compromise either the safety or the efficiency of operations if not adequately managed. In such cases preventing the human from having full control on the execution may lead to either losing the benefits expected from automation or generating undesired side effects.

At design level it is preferable to choose these ALs when it is not possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. Safely, because some relevant operational constraints may compromise the safety of operation if disregarded by the automation. Efficiently, because it may be not cost-effective to design an automation with the capability to consider all the relevant operational constraints.



Airborne ASAS ASPA

Airborne Separation Assistance System (ASAS) - Airborne SPAcing (ASPA) Sequencing and Merging (S&M) AL D4

The ASPA S&M function allows the acquisition and the maintaining of a time spacing instructed by the air traffic controller, between the trailer aircraft (or ownship) and a given target aircraft. For that purpose, the ASPA S&M function provides three manoeuvres.

1st manoeuvre: Remain behind manoeuvre

The two aircraft are following the same lateral flight plan. Following ATC instruction, the trailer aircraft has to acquire and maintain a time spacing (with a +/- 5s tolerance).

2nd manoeuvre: Merge then remain behind manoeuvre,

This manoeuvre applies for two aircraft having their trajectory merging at a given waypoint (merge waypoint). After ATC instruction, the trailer aircraft has to engage a maneuver to over fly the merge waypoint with the instructed time spacing. This spacing has to be maintained with a +/-5s tolerance.

3rd manoeuvre: Vector then merge behind manoeuvre.

This manoeuvre applies for two aircraft having their trajectory merging at a given waypoint (merge waypoint). The goal, for the trailer aircraft, is to lose time by following a ground heading instruction, before the merging point. This spacing has to be maintained with a +/-5s tolerance.

The choice of the manoeuvre is done by the controller and instructed to the flight crew. This choice depends on the relative position between the ownship (DLH456) and the target aircraft (AFR123) as illustrated in the pictures below.

Figure 30: The choice of the manoeuvre is done by the controller and instructed to the flight crew.

In terms of operational environment, the ASPA S&M application concerns end of en-route, descent and approach environment.

Design Implications

Remain behindRemain behind Merge then remain behindMerge then remain behind Vector then Merge Behind


79 of 97

ASAS ASPA S&M can be classified as automation support on level D4. Once the manoeuvre instructed, the flight crew activates ASPA S&M accordingly. The system performs automatically the action after activation by the human who is able to monitor and interrupt it. After activation by the pilot, ASPA S&M manages automatically the speed and the trajectory without pilot intervention in order to maintain the time spacing instructed by ATC between the trailer aircraft (ownship) and a given target aircraft.

The flight crew can monitor the progress of action and interrupt it during the execution. The system is automatically disengaged under certain conditions, e.g. under a given altitude or if autopilot is disengaged.

Available REOAs

ASAS ASPA S&M (Annex A – Section 4.1.2)

External References

ASAS ASPA S&M

o Advanced Merging and Spacing Concept of Operations for the NextGen Mid-Term (FAA, 2009)

o Package 1: Enhanced Sequencing and Merging Operations (ASPA S&M) – Application Description (RFG, 2009

o Project Initiation Report WP 9.05-Airborne Separation Assistance System - Spacing Sequencing & Merging (SJU, 2010)

o Functional requirement definition – ASPA S&M (SJU, issue 1.0)

o Verification and Validation Plan – ASPA S&M Application for Mainline Aircraft (SJU, 2010)


1) Lack of user involvement in automation assisted processes may lead to reduced vigilance and loss of situation awareness

2) Lack of user involvement in automation assisted processes may lead to loss of skills and proficiency

3) Lack of user involvement in automation assisted processes may impact recovery from system failure

5) The automation of routine tasks may remove an important information source which may reduce situation awareness.




The AL D5-D6 functions perform action implementation independently from human initiation. These functions should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. In such cases the best strategy for action implementation is giving full power for execution to the automated function, leaving to the human only the possibility to interrupt the process.

EXPLANATION


80 of 97

Compared to lower levels of action implementation support, the D5-D6 levels (AIS) allow less freedom to the human operator. Compared to D7 and D8, however, they maintain the full power for the human to monitor and interrupt the action execution.

At AL D5 the automated function initiates the action execution independently from the human but allows her/him to both modify and interrupt the execution. At AL D6 the action execution is also initiated automatically and the human is only allowed to interrupt it.

On the one hand this lower degree of freedom for the human may positively impact on the precision and speed of action implementation, reducing the opportunity for potential errors with negative effects on safety, especially in high workload and stressful situations. On the other hand the lower degree of freedom prevents the human from fully remaining in the control loop and from quickly correcting or interrupting the automation, in case of contextual changes or intervening variables which cannot be detected or managed by the automation itself. Nonetheless, the possibility for the human to interrupt the execution plays the role of a last safety barrier, in case of a negative course of action determined by the automation.

At design level it is preferable to choose these ALs when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation. Safely, because the most relevant operational constraints with an effect on safety are taken into consideration in the internal logic of the automation. Efficiently, because it is considered cost-effective to design an automation with the capability to consider all these operational constraints. Furthermore, it is preferable to choose these ALs, compared to the higher ones, when the automation is operating in an open environment and it is impossible to physically protect the working activities from external interferences.



Airborne - BTV ROP (same example presented in DAS 1.2)

- AP/FD TCAS

Brake To Vacate - Runway Overrun Protection AL D6 (preceded by AL C4)

BTV (Brake-To-Vacate) is an enhancement of the classical auto-brake system at landing. It allows pilots to select the runway exit they can reach, by visually indicating to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The auto-brake activates roughly at the moment when the nose landing gear are down. The system guarantees the aircraft to vacate at the assigned exit with optimization of the brake energy regarding current operational constraints (weather, runway conditions, etc.), with minimization of the runway occupancy, and improvement of the passenger comfort.

The objective of BTV coupled to the Runway Overrun Prevention and Warning System (ROW/ROP) is to prevent the runway excursion risk at landing. Pilots’ estimation of the aircraft touch-down may be approximate as it does not result from precise calculation. The ROW/ROP based on BTV is able to give this precise information thanks to the considerations of the airborne progress and the airport databases.


81 of 97

Figure 31: Triggering conditions of BTV ROW/ROP function.

ROW is an alert which triggers when the aircraft is in flight, indicating visually (on Airport Moving Map, and PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. In general, when this alert triggers, it is impossible for pilots to appropriately adjust approach parameters to recover the situation, then, the procedure applied is a go around.

ROP is an alert which triggers when the aircraft touches down, indicating visually (on Airport Moving Map, and PFD) and aurally (audio message) that the aircraft braking distance will overrun the runway. The ROP may generally not trigger because the ROW should trigger before, but it may happen that the runway conditions are wrongly estimated and the ROP triggers the same alarm. Moreover, the ROP function associates also the auto-brake system to the alarm. This one activates automatically the maximum braking at the aircraft touch-down.

Design Implications

The ROP function triggers an alert once the aircraft is on ground, in case the aircraft is unable to stop before the end of the runway. The system is able to assess the situation and decide to brake with maximum energy if the aircraft risks of overrunning the runway end. That is why the AL C4 is also applicable to this system. The ROP is systematically accompanied with the maximum braking action of the aircraft. AL C4 is followed by AL D6 because the system decides and initiates the action of braking. Pilots can override this automation only by interrupting the operation and take the aircraft control manually.

Generally, the ROP function should never trigger if pilots make a corrective action when the ROW triggers (the corrective action in flight is the landing avoidance with the go around). But, it may happen that the ROP triggers but not the ROW, in case, for example, the runway conditions have changed before touch-down. In this case, the maximum automatic braking activates automatically at the aircraft touch-down in the same time as the alert.

Auto Pilot/ Flight Director TCAS mode AL D6

The AP/FD TCAS mode enhances the existing TCAS functionality by implementing a TCAS vertical guidance feature into the Auto Flight computer. The AP/FD TCAS mode enhances the existing TCAS functionality by implementing a TCAS vertical guidance feature into the Auto Flight computer. This new mode controls the vertical speed of the a/c on a vertical speed target acquired from TCAS which is adapted to each RA. The focus in this example is on the case of an AP engaged giving the possibility to fly a required TCAS RA avoidance manoeuvre automatically.


82 of 97

Figure 32: The TCAS RA on Primary Flight Display without AP/FD TCAS mode.

Figure 33: The TCAS RA on Primary Flight Display with AP/FD TCAS mode.


83 of 97

Figure 34: Safe altitude capture with AP/FD TCAS mode.

Design Implications

With the AP/FD TCAS mode concept, the pilot is supported in flying the RA manoeuvre (D6). The pilot has the possibility to disconnect the AP and FD at any moment and to respond to the RA by flying the avoidance manoeuvre according to the conventional procedure.

With the AP/FD mode concept the crew’s workload and stress level by conducting the RA manoeuvre is expected to be reduced. Moreover a disruption in the flying technique when an RA is received can be eliminated. The pilot no longer needs to disengage the Auto Pilot or Flight Directors before conducting the TCAS manoeuvre. This support in executing the avoidance manoeuvre will help to avoid inappropriate reactions in case of RA (late, over, or opposite reactions) or other misbehaviour when the aircraft is clear of conflict. It is AL D6 because the system initiates and executes the action and the human can monitor and interrupt it.

Available REOAs


AP/FD TCAS (Annex A – Section 4.1.1)

External References

o Airbus FAST Magazine #44 / December 2009: http://www.airbus.com/support/publications/

o Airbus (2009). Airbus new Auto Pilot/Flight Director TCAS mode. Retrieved from http://www.airbus.com/fileadmin/media_gallery/files/brochures_publications/FAST_magazine/fast45-04-new-auto-pilot.pdf


9) Progressive shift from skill/rule-based task to knowledge-based tasks may result in increased response times or increased risk of errors by operators




84 of 97



15) Data fusion and filtering in automated support systems may reduce ATCO and pilots’ accessibility to relevant information, with negative impact on decision making processes and situation awareness


AL D7-D8 functions give limited or no opportunity to the human operator to monitor and interrupt an automated process. These functions should be preferred when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation in a physically protected environment, with limited risk of external interferences. In such cases the best strategy for action implementation is giving full power for execution to the automated function, leaving the human virtually out of the control loop, with limited or no possibility to monitor and interrupt the ongoing process.

EXPLANATION

Compared to lower levels, these levels of action implementation support (AIS) are virtually replacing the human operator role.

At AL D7 the automated function initiates the action execution independently from the human and leaves her/him only limited opportunities to monitor or interrupt it. At AL D8 the automated function initiates the action execution independently from the human and prevents her/him from any monitoring and interruption, until the execution is not terminated.

On the one hand replacing the human may positively impact the precision and speed of action implementation, giving virtually no opportunity for errors with negative effects on safety, especially in situations that would be stressful for a human or characterized by high workload. On the other hand replacing the human does not leave the opportunity to the human to correct or interrupt the automation, in case of contextual changes or intervening variables which cannot be detected or managed by the automation itself, with no possibilities to mitigate a potential negative course of action determined by the automation.

At design level it is preferable to choose these ALs when it is possible to safely and efficiently isolate a limited set of parameters and variables to be managed autonomously by the automation, but also to physically protect the environment in which the automation is operating from external interferences. Safely, because the operational constraints with an effect on safety are all taken into consideration in the internal logic of the automation and can all be managed inside a dedicated protected environment. Efficiently, because it is considered cost-effective to design an automation with the capability to consider all these operational constraints and to build up a physical protection of the concerned environment that will defend it from major external interferences.


Ground Not applicable to ATM?

Airborne


85 of 97

Examples from other (non-ATM) domains AL D7 & D8

Although a definite conclusion cannot be drawn in this context, the AL D7 and D8 are unlike to be applicable to the ATM domain. The management of air traffic is by definition a complex socio-technical domain, involving a huge number of actors, including people and technologies which are generally interacting in an open operational environment. Therefore it is difficult to imagine that even a limited part of this system could be managed by completely replacing the human operator role and without giving any opportunity to a human operator to monitor and interrupt an ongoing process, which is activated independently from any human being.

A washing machine can be considered as a very basic example of automation working at AL D7/D8. It can be programmed to start the washing process at a defined time, with no need for user assistance when the process is starting. In addition a washing machine can generally work unattended also for several hours, with no need for monitoring or supervision. In some cases (e.g. coin operated public laundries) the user might be even prevented from interrupting the washing process, once this has been activated. All these conditions are actually possible and considered safe enough because the washing machine can work according to a limited set of predefined parameters and settings and it is designed as a closed environment, mostly protected by external interferences. Even in case of failure - both external (e.g. loss of power supply) or internal (e.g. water filter not working properly) - a closed environment and a few fail safe-features (e.g. door prevented from suddenly opening during a washing program) ensure that the worst imaginable damage will be either a water leak or a black out.

Some successful attempts to design automations at AL D7 have also been made in transportation domains different from ATM. A typical example is the unmanned trains of some urban metro or shuttles systems (see an example in Figure 35). Although these systems are also tele-operated by a human from the distance, considerable parts of the transportation process can be made with no or very limited human supervision. Also in this case however, creating an environment protected by external interferences is an essential condition.

Figure 35: Example of unmanned train coach of the Metro transportation system in Toulouse.

For example these systems are generally based on dedicated train tracks which should be – to the extent possible – physically protected by external interferences. No interference should be possible with other transportation means (as for traditional trains) and the uploading and offloading of passengers should be managed in a way to completely prevent the access of people to the train track (see in Figure 36 the example of glass protective barriers in a typical station of the Metro system in Toulouse).


86 of 97

Figure 36: Example of a Toulouse Metro station with glass barriers.

Available REOAs

Not available

External References

Not available



2) Lack of user involvement in automation assisted processes may lead to loss of skills and proficiency

3) Lack of user involvement in automation assisted processes may impact recovery from system failure

5) The automation of routine tasks may remove an important information source which may reduce situation awareness.

5.5 Design Principles transversal to automations supporting different cognitive functions (TRA)

TRA-1: COMBINED SUPPORT TO COGNITIVE FUNCTIONS

When feasible, prefer design solutions providing combined support to more than one cognitive function with the same HMI element

EXPLANATION

It is quite common to have automated functions supporting at the same time more than one cognitive function (e.g. information acquisition and information analysis or information analysis and decision and action selection, etc), however this is commonly achieved by means of different HMI elements. For example a visual alert to highlight the result of an analysis made by the automation or a menu with different options to support the decision making.

In principle the greater the number of HMI features to be perceived and used by the human (such as


87 of 97

visual or auditory elements, advisories, alerts, triggers, menus, pointers, etc.) to support different cognitive functions, the higher will be the cognitive workload experienced by the user, especially when the HMI features rely on the same sensory modality (e.g. the visual or auditory channel). On the other hand a limited number of HMI features are likely to offer support to only one or a few cognitive functions. A better compromise is reached when it is possible to combine in the same HMI element the support to more than one cognitive function.

Note that supporting different cognitive functions does not necessarily mean supporting different operations. As a matter of fact to have the same HMI element (e.g. a lever, a button, a led, etc) supporting more than one operation, it is normally required to switch from one functionality mode to the other. However such a concentration of operations within the same HMI element may increase the risk of mode errors (e.g. the user is pressing a button to perform a certain action and does not realize that the active mode makes the button perform a different action). Therefore the combined support to more than one cognitive function within the same HMI element provides real benefits only when it does not imply using the same HMI element to perform too many types of operations.


Ground - CATO What-if Probing Tool

Airborne - D-TAXI

CATO What-if Probing Tool AL B3 combined with AL C2

The CATO (Controller Assistance Tools) - What-if-probing is part of a set of controller tools currently being investigated by DFS for lower level airspaces. It is a functionality used by the ATCO to check if cleared flight levels or direct inputs would be conflict free for a certain time horizon. The what–if probing computes potential conflicts for a configurable time horizon, (the next 6 minutes for lower sectors or 8 minutes for upper sectors) for aircraft that violate either the 6NM lateral or 700 ft vertical separation criteria. Hence, the what–if probe has a time buffer of 2 minutes before an ECS conflict is displayed (ECS states for Executive Conflict Search and it is the name of an associated conflict detection tool).

Figure 37 shows the example of an aircraft with call sign RYR4SX triggering an ECS warning. In parallel to it the what-if probing window is open and shows the results of the what-if probe calculation. Green flight levels are free of conflicts, blue flight levels need to be combined with a cleared (green) rate to be free of conflicts, and orange flight levels are not free of conflicts regardless of specifying a rate.

The concept behind the displayed options is to provide a controller with flight levels that will not cause further conflicts if selected.


88 of 97

Figure 37: What-if probing for flight levels displayed in the CFL menu.

On the other hand the what-if probing functionality for direct route inputs (Figure 38 below) shows conflict free direct routes possibilities in green. The waypoints displayed in red may also be selected but will cause a potential conflict according to the trajectory prediction.

Figure 38: What-if probing for directs.

Design Implications

The specific design solution proposed for this functionality supports at the same time the information analysis and the decision and action selection cognitive functions, in a context in which the information acquisition regarding the position of each a/c is already supported by the usual multi-radar tracking system on the controller working position.

The information analysis is given at AL B3: based on user request, the system calculates for the user if a certain level change or route change will cause a conflict. If a conflict is identified an ECS alert will be triggered.

While the decision and action selection is given at AL C2: by way of a colour coding (the green, blue and orange representing the different conditions) the automation is proposing to the user one or more alternative options, based on pre-computations by the system. The user can choose one of the proposed options or an alternative one, but s/he is already aware of what is considered feasible by the system even before performing any selection action. Thanks to this feature the cognitive distance between action execution and action evaluation is virtually cancelled. In case the users has sufficient trust in the system there is a potential for saving valuable time (the time required for selecting an option and waiting for the response of the system) and cognitive resources (the resources required to spot potential conflicts associated to the route or level change).


89 of 97

D-TAXI AL A3/A4 combined with AL D2

The D-Taxi Function – Graphical Route Display is a function used to enhance the flight crew situation awareness and to provide assistance to the navigation without using navigation charts.

The function is supported by two systems:

OANS (On-board Airport Navigation System), that allows the electronic map display including the own ship position display on the airport and the graphical taxi route.

ATIMS (Air Traffic and Information Management System), which allows the data link communication between pilots and controller and the display of taxi clearances, in a textual way.

The two systems are complementary to support the graphical display of the taxi route, as OANS needs ATIMS information and the graphical route on airport moving map is based on the computation of the textual information/clearances of the data link message and on its conversion in graphical format on the airport moving map.

The graphical route display allows both the visualisation of own aircraft position in the airport layout and a visual guidance to perform a correct taxi routing, according to the clearance given by the ATC (see Figure 39).

Figure 39: Example of a graphical taxi route display for taxi-out operation on Paris CDG airport.

The function is expected to provide benefits in complementing the usual out-of-the-window scan, with clear added value in case of low visibility conditions. Furthermore it supports the correct interpretation of the taxi path instructed in the clearance, reducing the risk of errors or misunderstandings with ATC.

Design Implications

In practice the adopted design solution combines onto the same HMI element the dynamic visualization of the own ship into the airport layout and the visualization of the taxi path instructed by ATC. In this way the automation provides first of all a support to information acquisition (AL A3 or AL A4 according to the way the clearance is received, i.e. by voice the pilot has to enter it manually or by data link) because the pilot can observe in its context the taxi route that the aircraft is required to follow thanks to the integration of information coming from different sources. Then, with the same HMI feature, the pilot is supported during her/his action implementation (AL D2), since the possibility to observe the movements of the own ship in relation to the planned taxi route provides a feedback on whether the a/c is following the correct path or not. Therefore the support to the two different cognitive functions is naturally integrated in only one HMI feature. Although the support is at a relatively low level of automation in both cases, the user can take benefit of it in the context of the

0922Z FROM LFPG WILCO

TAXI TO

HOLDING POINT Y11 RWY

27L

VIA A NA1 N BD5 D Y11

VIA RT19 W10

CLOSE*

RECEIVD BY ATC

0922Z FROM LFPG WILCO

TAXI TO

HOLDING POINT Y11 RWY

27L

VIA A NA1 N BD5 D Y11

VIA RT19 W10

CLOSE*

RECEIVD BY ATC

The pilot has acknowledged the taxi clearance

(WILCO+ SEND)

AIRBUS PROPERTY


90 of 97

same perceptual task, with no increase of the required cognitive resources.

Note: the picture above shows the principle of the functioning, but does not necessarily reflect the exact current HMIs (definition still in progress and continuously changing).

Available REOAs

CATO What-if Probing Tool (Annex A – Section 4.2.3)

D-TAXI (Annex A – Section 4.1.8)

External References

D-TAXI






TRA-2: FEEDBACK

Independently from the chosen automation level, an automated function should always provide a clear feedback in response to the inputs and actions by the user. Based on such feedback the user should always know:

- if the automation has actually received the input by the user

- if the action of the user has achieved the desired result or if progresses have been made in the direction desired by the user

EXPLANATION

A good feedback is an essential requirement for an automated function to really support the human performance. There is no need that the human operator is aware of the internal functioning of the automation, however, in order to have a good control of the interaction with the automated function, the user should always be aware of the effect of the actions s/he is performing on the concerned working process by way of the automation itself.

The format of a good feedback can be very variable depending of the chosen automation level and on the experience which is expected by the user in a specific application domain. As a general rule, however, a feedback will be more effective if the temporal and physical distance between the input of the user and the response by the system is minimized.

If feedback is lacking, difficult to perceive or provided to late there is a risk that the user will lose control of its interaction with the system and that his/her performance will be jeopardized by an excessive workload and increased number of errors.




91 of 97

Ground Not Available

Airborne - Feedback during execution of a corrective TCAS Resolution Advisory avoidance manoeuvre (with AP/FD TCAS mode)

Corrective TCAS Resolution Advisory with Auto Pilot/Flight Director mode

Traffic Alert and Collision Avoidance System (TCAS) is an onboard system that has been introduced to reduce the risk of mid-air collisions between aircraft. TCAS monitors the airspace for other aircraft equipped with a corresponding active transponder around an aircraft. The TCAS display is integrated in the Navigation Display of the Cockpit and alerts the pilots of presence of other aircraft in a protected volume. Besides identifying potential collisions, TCAS alerts the pilot by issuing the following types of aural annunciations: Traffic Advisory (TA), Resolution Advisory (RA) and Clear of Conflict.

The AP/FD TCAS mode enhances the existing TCAS functionality by implementing a TCAS vertical guidance feature into the Auto Flight computer. This new mode controls the vertical speed of the a/c on a vertical speed target acquired from TCAS which is adapted to each RA. With the AP engaged, the function supports the pilots in flying automatically a required TCAS RA avoidance manoeuvre.

Figure 40: Indications on the Primary Flight Display (PFD).


92 of 97

Figure 41: The execution of the RA avoidance manoeuvre with its aural and visual feedback provided.

[Pictures taken from Airbus FAST magazine No. 45 Airbus new Auto Pilot/Flight Director TCAS mode: Enhancing flight safety during TCAS manoeuvres http://www.airbus.com/support/publications/]

Design Implications

Feedback is important independent of all automation levels. However this example shows that continuous feedback is provided while the AP/FD TCAS mode executes the corrective RA avoidance manoeuvre.

It is important to note that aural feedback (via the Flight Mode Annunciator) and visual feedback (via display and vertical speed indicator) are combined occurring simultaneously. The flight mode annunciator (represented with the green speech bubbles) provides feedback by voice, such as ‘clear of conflict’ so that the flight crew is aware when the manoeuvre is executed and they are established on the selected and ‘safe’ FL.

Moreover by the indications on the PFD and in particular the vertical speed indicator (VSI), the flight crew can instantaneously consult feedback on the manoeuvre execution in progress. The VSI and the colour coding also allow the flight crew to situate the ownship at any moment: The green area represents the allowed vertical speed domain, while the red area indicates the forbidden vertical speed domain.

Available REOAs

Auto Pilot / Flight Director Traffic Collision Avoidance System (AP/FD TCAS) (Annex A – Section 4.1.1)

External References

Auto Pilot / Flight Director Traffic Collision Avoidance System

Airbus FAST Magazine #45 / 2009: http://www.airbus.com/support/publications/




12) Poorly designed automation may lead to simultaneous tasks competing for user attention or causing interruptions of high workload activities, reducing efficiency and increasing the risk of human




93 of 97

error



19) Lack of awareness of mode of operation may reduce efficiency and increase the risk of human error

TRA-3: MODE ERROR PREVENTION

When an automated function can be configured to work according to different modes, it is essential that the user is always made aware of the active mode and timely informed of any mode change. To the extent possible the HMI design should contribute to minimize the risk of mode errors.

EXPLANATION

Mode errors are a classical problem associated to the use of automation and to the use of software tools in a wide sense. Most of the automated functions are actually designed to work according to different modes. Depending on the selected mode, the same or very similar actions or input by the user will have different effects on both the automation and the concerned operational environment. Therefore in case the user is not aware of the active mode or has not detected a previous mode change, there is a risk that the automated function will perform an action which is unexpected by the user (a phenomenon also defined as automation surprise). In the most positive case the consequence of a mode error will be the need for the user to repeat a previous action or to establish a new action plan, with negative effects on the efficiency of operations. While in the most negative case as mode error may result in a serious risk for safety.

At HMI level it is essential that very different modes (i.e. modes that will make the automation to behave in significantly different manners) are represented in way that allows the user to clearly distinguish them.

Furthermore, as for feedback (see previous TRA-2 principle), any mode change, both automatic or resulting from a user input, should be timely and clearly advised. If the mode change is automatic, the user should be in condition to perceive it as close as possible to the other functions and tools which are expected to be used in the same operation phase. If the mode change is the result of a user input, its notification on the HMI should be physically as close as possible to the place of the user input.


Ground Not Available

Airborne - Brake to Vacate

Brake to Vacate (BTV) - Autobrake

BTV is an enhancement of the classical auto-brake system at landing. It allows pilots to select the runway exit they can reach, by visually indicating to the crew the minimum braking distance they need regarding the aircraft performance and runway conditions. The enhanced auto-brake system allows the aircraft to optimally reach the designated runway exit. The auto-brake activates roughly at the moment when the nose landing gear are down. The system guarantees the aircraft to vacate at the assigned exit with optimization of the brake energy regarding current operational constraints (weather, runway conditions, etc.), with minimization of the runway occupancy, and improvement of the passenger comfort.


94 of 97

Previously to the landing phase it is essential that the crew is aware of the active mode of the BTV function to have a correct expectation on how the auto-brake is going to behave. Particularly the pilots should know whether the BTV function is armed or not and which is the exit (previously selected) for which the auto-brake is optimized. In the cockpit the information regarding this modes are presented as follows:

- As a textual indication (see red arrow in the Figure 42) on the FMA (Flight Mode Annunciator), which is part of the Primary Flight Display, including other features information such as airspeed, altitude, pitch/roll angle, heading, rate of climb, set barometric pressure, etc.

Figure 42: Example of the BTV indication in the Flight Mode Annunciator. [Pictures taken from Airbus FAST magazine No. 44 Brake-to-Vacate system: The smart automatic

braking system for enhanced surface operations http://www.airbus.com/support/publications/]

- As a textual indication On the Navigation Display, below the indication of the type of approach (in the example of Figure 43 this is “ILS”). The active mode is here associated to the indication of the selected runway (‘14R’) and selected exit (‘M4’).

- With the Auto-break rotary switch set on BTV (see again Figure 43).

Figure 43: The Navigation Display.

Design Implications

The displayed “BTV” indications are both in physical proximity to other display features which are carefully observed by the crew when flying the final segment, previously to the landing phase. Furthermore the BTV label indication onto the rotary switch makes apparent which mode has been



95 of 97

selected by the pilot in physical proximity to the place where this input was inserted.

Available REOAs

Brake to Vacate (BTV) – Autobrake (Annex A – Section 4.1.5)

External References

BTW (Brake to Vacate)

Airbus FAST magazine No. 44 Brake-to-Vacate system: The smart automatic braking system for enhanced surface operations http://www.airbus.com/support/publications/


1) Lack of user involvement in automation assisted processes may lead to reduced vigilance and loss of situation awareness.


19) Lack of awareness of mode of operation may reduce efficiency and increase the risk of human error



96 of 97

6 References [1] Anderson, J. R., & Lebiere, C. (1998). The atomic components of thought. Mahwah, NJ:

Erlbaum.

[2] Cabon, P., Rome, F., Mollard, R., Vollard, C., & Reuzeau, F. (2007). Calibration of mental workload measures during the design process of future Airbus military transport aircraft : the workload assessment method. Aviation, Space and Environmental Medicine, 78(3), 289-292.

[3] Card, S., Moran, T., and Newell, A.. (1980). The keystroke-level model for user performance time with interactive systems. Commun. ACM 23, 7 (July 1980), 396-410.

[4] Endsley, M.R., & Kaber, D.B. (1999). Level of automation effects on performance, situation awareness and workload in a dynamic control task. Ergonomics, 42, 462– 492.

[5] EUROCONTROL HIFA, http://www.eurocontrol.int/hifa/public/subsite_homepage/homepage.html.

[6] EUROCONTROL (2003). The development of situation awareness measures in ATM Systems.

[7] FAA Workbench, http://www.hf.faa.gov/portal/default.aspx.

[8] Farmer, E. et al. (2003). Review of Workload Measurement, Analysis and Interpretation Methods. Eurocontrol - CARE-Integra-TRS-130-02-WP2.

[9] John, B.E., Salvucci, D.D, Centgraf, P., Prevas, K., (2004) Integrating models and tools in the context of driving and in-vehicle devices. Proceedings of International Conference on Cognitive Modeling (Pittsburgh. PA July30 – August 1 , 2004).

[10] Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics – Part A: Systems and Humans, 30, 286–297.

[11] Salmon, P.M., Stanton, N.A., Walker, G.H., and Green, D. (2006). Situation awareness measurement: A review of applicability for C4i environments. Applied Ergonomics, 37, (2), 225-238

[12] SESAR Joint Undertaking (2007). SESAR ATM Target Concept D3. DLM-0612-001-02-00a.

[13] Sherry, L., John, B., Blackmon, M., Polson, P., Medina M.,Teo, L., (2010). System Design and Analysis: Tools for Automation Interaction Design and Evaluation Methods. NASA NRA NNX07AO67A

[14] Sheridan, T. B., & Verplank, W. (1978). Human and Computer Control of Undersea Teleoperators. Cambridge, MA: Man-Machine Systems Laboratory, Department of Mechanical Engineering, MIT.

[15] Teo, L., and John, B.E. (2008). CogTool-explorer: towards a tool for predicting user interaction. In CHI '08 Extended Abstracts on Human Factors in Computing Systems, 2793-2798. Florence, Italy.

[16] Wickens, C.D., Mavor, A.S., Parasuraman, R. & J.P. McGee (Eds), 1998. Commission on behavioural and social sciences and education in The Future of Air Traffic Control: Human operators and automation. Washington DC: National Academy Press.

Related Documents

SESAR Joint Undertaking (2010). Identification and Integration of Automation Related Good Practices. WP 16.05.01 Project Initiation Report. Version 00.01.03.

SESAR Joint Undertaking (2011). Identification of Issues in HP Automation Support. WP 16.05.01 Deliverable 02.

SESAR Joint Undertaking (2011). Framework for HP Automation Related Good Practices. WP 16.05.01 Deliverable 03.


97 of 97


98 of 97

- END OF DOCUMENT -