Air Traffic Control automation: integration with a simulation

environment for the evaluation of a Decision Support Tool

João Pedro Malés Pereira

Thesis to obtain the Master of Science Degree in

Aerospace Engineering

Supervisor: Prof. Doutor Rodrigo Martins de Matos Ventura

Examination Committee
Chairperson: Prof. Doutor João Manuel Lage de Miranda Lemos
Supervisor: Prof. Doutor Rodrigo Martins de Matos Ventura
Members of the Commitee: Eng. José dos Santos Vermelhudo

October 2014
Acknowledgments
A thesis is never a one-man show. Mine is no exception and thus I want to express my gratitude
to various people for varied reasons.
For starters, I want to thank my supervisor Prof. Rodrigo Ventura for always being there and
always guiding me in the right direction. Also, for putting me in contact with air traffic controller
Nelson Pimentel, whom I also want to thank for the time dispensed and for all the valuable insight
and material about Santa Maria FIR’s procedures.
Then, I want to thank both the virtual controllers that agreed to take some of their own free time
to help this thesis by accepting to participate in the trials. Thank you José Pereira and Miguel
Frias for helping me make the results of this thesis more reliable.
I also want to leave a note of gratitude to Gergely Csernak, the creator of the air traffic simulator
Euroscope, for helping me throughout the plug-in making. There was not much information about
the subject on the internet and some of the problems could not have been solved without his help.
At least, but not at last, I want to leave a special thanks to my family, friends and girlfriend
that were with me throughout this 6 years of university while I followed a path that led me into
becoming a Master in Aerospace Engineering. Without them, even with the remote possibility of
achievable, that path would have been a lot more boring and lonesome.

iii
Abstract
Because of the significative air traffic increase that has been occurring in the past decades,
automation of Air Traffic Control (ATC) operations can be considered in a long-term as a method to
cope with this problem. The development of Decision Support Tools (DST) to help ATC Operators
(ATCO) diminish their workload is an intermediate step between a possible future of having a
predominantly automated system and a mostly manual, human-controlled one, as in the present.
In the sequel of a previous MSc thesis at IST, a DST for controllers of enroute positions was
made. The DST receives a flight scenario and finds an optimal solution that prevents conflicts
until the end of the aircraft trajectories within a given Flight Information Region (FIR). Simulations
were conducted with various scenario files with different traffic density and complexity and the
DST proved its robustness.
In order to transform a concept into a DST that is fully integrated with the ATCO system, there
are numerous stages. This thesis aims at looking into two of those stages: transform the previ-
ously created DST into a real-time, integrated with an air traffic simulation environment DST; test
it with ATCOs to evaluate its usability. A plug-in was made in order to make the bridge between
the DST and the air traffic simulator and the specific problem of oceanic airspace was taken into
account as a case study.

Keywords: ATC automation, DST, oceanic control, plug-in.

v
Resumo
Devido ao aumento significativo de tráfego aéreo que se tem verificado nas últimas décadas,
a automação de operações do Controlo de Tráfego Aéreo (Air Traffic Control, ATC) pode ser
considerada uma metodologia de longo prazo para resolver este problema. O desenvolvimento
de Ferramentas de Ajuda à Decisão (Decision Support Tools, DST) para ajudar os Controladores
de Tráfego Aéreo (ATC Operators, ATCOs) a diminuir a sua carga de trabalho é um meio-termo
entre um possível futuro de ter um sistema predominantemente automatizado e um manual,
controlado por humanos, como o que se verifica atualmente.
Na sequência de uma tese MSc realizada no IST, uma DST para controladores que supervi-
sionam a fase de cruzeiro foi efetuada. Esta DST recebe um cenário com voos e encontra uma
solução ótima até ao fim das trajetórias dos aviões numa dada Região de Informação de Voo
(Flight Information Rules, FIR). Várias simulações foram conduzidas com um leque variado de
densidades e complexidades de tráfego, tendo a DST provado a sua robustez.
Há muitas etapas a seguir de forma a transformar um conceito numa DST integrada com o
sistema de ATC. Esta tese olha para duas delas: transformar a DST previamente criada numa
em tempo real e integrada com um sistema de simulação de tráfego aéreo; testá-la com ATCOs
de forma a atestar a sua funcionalidade. De modo a fazer a ponte entre a DST e o simulador de
tráfego aéreo, criou-se e testou-se um plug-in para o caso específico do controlo oceânico.

Keywords Automação de ATC, DST, controlo oceânico, plug-in.

vii
Contents

Abstract v

Resumo vii

List of Figures xi

List of Tables xiii

Nomenclature xv

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Limitation of the DST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Thesis contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 System Architecture 5
2.1 DST description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Trajectory prediction routine . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Conflict detection and resolution routine . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Plug-in communication with the DST . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Input/Output analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Simulated time to real-time . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Limitations and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 Impossibility of using the interactive solution . . . . . . . . . . . . . . . . . . 17

3 Simulation Environment and Plug-in Description 19

3.1 Simulation environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Plug-in description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Computational languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ix
 3.2.3 Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 Designed interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Plug-in - DST connection periodicity . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Additional window for Euroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Simulation and Results 35

4.1 Simulation framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Simulation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Traffic generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Trials with ATCOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Pilot trial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Inquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2 Qualitative feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 Conclusions 47
5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Bibliography 51

A ATCOs Template Survey 53

B ATCOs Answered Surveys 55

x
List of Figures

2.1 Deviation integral illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Pareto optimal set calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Mean values for trun as a function of NF . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Scheme of the communication between the plug-in and the DST . . . . . . . . . . 12
2.5 Scenario demonstrating a conflict between two aircraft flying inside LPPO . . . . . 16
2.6 New scheme of the communication between the plug-in and the DST . . . . . . . . 18

3.1 Print screen of the simulation environment Euroscope . . . . . . . . . . . . . . . . 20

3.2 Zoom in of figure 3.1 to show different aircraft in greater detail . . . . . . . . . . . . 20
3.3 Flowchart of the most important plug-in’s routines . . . . . . . . . . . . . . . . . . . 25
3.4 Print screen of Euroscope with the plug-in loaded . . . . . . . . . . . . . . . . . . . 26
3.5 Interactive plug-in’s interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Interactive plug-in’s display area under different configurations . . . . . . . . . . . 29
3.7 Non-interactive plug-in’s interface displaying a set of instructions . . . . . . . . . . 30
3.8 Details of the final plug-in’s interface version . . . . . . . . . . . . . . . . . . . . . . 32
3.9 Waypoint reports window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Entry counts in the LPPO during 9th January 2014 . . . . . . . . . . . . . . . . . . 41

xi
List of Tables

2.1 Example of flight plan for aircraft that is already inside the LPPO . . . . . . . . . . 13
2.2 Differences between the call to the DST, before and after the solution was applied 17

4.1 Scheme plan of the experiments with four controllers . . . . . . . . . . . . . . . . . 41

4.2 Scheme plan of the experiments with two controllers . . . . . . . . . . . . . . . . . 43

xiii
Nomenclature
Acronyms

ATC Air Traffic Control

ATCO Air Traffic Control Officer

ATM Air Traffic Management

CD&R Conflict Detection and Resolution

DLL Dynamic-Link Library

DST Decision Support Tool

ETA Estimated Time of Arrival

EUROCONTROL European Organisation for the Safety of Air Navigation

FFP Filed Flight Plan

FIR Flight Information Region

FL Flight Level

ICAO International Civil Air Navigation

LPPO ICAO code for Santa Maria FIR

MFC Microsoft Foundation Classes

RFL Requested Flight Level

RVSM Reduced Vertical Separation Minimum

xv
Chapter 1

Introduction

1.1 Motivation
Air traffic demand is anticipated to grow substantially in the next decades. European Organi-
zation for the Safety of Air Navigation (EUROCONTROL) projects in its air traffic flow forecast for
2012-2035 [1] that, in the most-likely scenario, 14.4 million flights will be handled by the states
of EUROCONTROL en route traffic control centers in 2035, as compared to 9.5 million aircraft
handled in 2012 – an increase of 50% by 2035 is expected. This predicted increase can only be
verified if the capacity for managing considerable higher traffic than today can be provided.
At this moment, the main factor restricting en route capacity is the high Air Traffic Control Offi-
cer’s (ATCO) workload, due to the constant need of providing proper separation between aircraft.
So, in order to keep the ATCO’s workload at a bearable level, automation in the form of Decision
Support Tools (DSTs) need to take a more active role in Air Traffic Management (ATM).
The current strategies for automation differ on the level of involvement that they require from
controllers. The best ones in near-term are still human-in-the-loop approaches, where the DST
includes the ATCO in the decision loop and thus makes the whole process more trustworthy in
the ATCO’s eyes. A study on ATCOs behavior performed by the National Aerospace Laboratory
of Netherlands in 2003 [2] shows that by completely removing the human from the control loop,
entrusting him with the role of passive monitor only, automation can hinder the operator’s ability to
maintain an adequate mental representation of the system, as well as inhibit his ability to quickly
reassure manual system in case of emergency – this phenomenon has been referred to as out-
of-the-loop unfamiliarity problem (Wickens [3] in 1992).
An interactive DST inserted in the human-in-the-loop automation strategy, supervising the
cruise phase of flights was done as part of a thesis at Instituto Superior Técnico [4] in 2013.
Given a flight scenario with multiple aircraft, the DST detects all potential conflicts inside a given
Flight Information Rules (FIR) throughout a finite time horizon and proposes a solution consisting
of Air Traffic Control (ATC) instructions to the operator that prevent the referred conflicts.
DST’s solutions are guaranteed to be optimal and the instructions given within them are only
in the form of Flight Level (FL) changes and delivered at reported fixes only, both policies imple-
mented so as to comply with the conventional oceanic ATC procedures that are currently done.
The DST was developed using the Python language and its validity was assessed through exper-
imental data.
The ATM system is a 24-hour, 7-day-a-week operation and any technological improvement
needs to be fully scrutinized before implemented. Thus, the stages and time behind the transfor-

1
mation of an idea, a concept into an actual DST validated to be used by real controllers in real
ATM are often very numerous and lengthy. Matos and Marsh [5] describe the stages for valida-
tion of a new decision support system and conclude that the validation of the early stages is of
extreme importance since it enables the study of how a new system of people and machines will
behave, before reaching a situation when it would be very costly to go back or to make changes.
This thesis proposes to take the previously made DST into the next steps of the validation
process, necessary for every DST present in the ATM system, focusing on two of those important
stages: first evolve it from the offline and limited DST that was previously created into an online
and fully integrated – in the form of a plug-in – with a simulated ATM environment DST; then, test
it with ATCOs to attest for its functionality.
Regarding the plug-in making phase, some considerations must be taken into account. It was
shown – again in the study done by the National Aerospace Laboratory [2] – that even in human-
in-the-loop approach, where humans are involved in the control loop, special attention when de-
signing the DST is needed in order to truly benefit the ATCO’s workload. If not, the controller, for
lack of trusting and understanding about the DST, will run a simultaneous self-derived solution and
a subsequent comparison with the automation’s solution which will increase the mental workload.
Kirlik in 1993 [6] demonstrated that an automated aid can go unused if the cost of initiating the
aid, considering its advice, generating one’s own solution and comparing solutions becomes too
high.
Thus, attention was paid when building the plug-in: making it the maximum intuitive as possible
and adding some pre-simulation high level explanation about the DST’s way of finding solutions.
This way ATCOs, by working with a cognitive tool and having some insight about the DST, are
more likely to trust the DST’s provided solutions and to find them transparent, i.e. easy to deter-
mine if they are correct or not.

1.2 Objectives
The objective of this thesis is to integrate the previously constructed DST with an ATM simulation
system, in the form of a plug-in, with the goal of evaluating it when integrated with the man-
machine interface used in the ATCO training. The thesis was divided in two phases:

1. Integrate the DST with the ATM simulation system by constructing the necessary middle-
ware. The built middleware should:

a) Feed the DST with the list of active flight plans with oceanic clearance;
b) Feed the DST with the aircraft’s reports in real-time;
c) Show, in the interface, the list of suggested decisions calculated by the DST;
d) Allow the ATCO the possibility to withhold the suggested decisions while informing the
DST of that withholding. A new lot of suggested decisions may be given.

2. Evaluate qualitatively the developed system, resorting to a set of ATCOs who were to be
subjected to a number of tests. For comparison effects, they would be tested in the simulated
scenarios with and without the usage of the DST.

2
1.2.1 Limitation of the DST

At a time when most of the plug-in’s construction was already carried out, it was discovered
a bug in the thesis where the DST was developed [4] that could not be solved – more on this in
chapter 2. This bug was deterrent of having the interactive part of the plug-in implemented, i.e.
point 1d of the initial objectives.
Because of this, a redefinition in the thesis objectives had to took place and the interactive part
of it had to be withdrawn. Thus, the ATCOs had to be relegated to a role of settling for the DST’s
suggested set of instructions, instead of collaborating with it in search for better suited solutions.
Throughout this thesis is still presented the work and research made on the plug-in construc-
tion under the initial objectives – since the work was carried out and is still valid under different
conditions – and the differences between that and the one designed because of the objectives
reformulation are explained along the way.

1.3 State of the art

ATM automation has been extensively researched in the past decades and many projects have
been made in order not only to simulate the ATM environment but also to test it with different
DSTs, so as to serve as ground-base for important steps in the validation of a DST.
One of these projects is the Highly Interactive Problem Solver (HIPS). It is a software for visu-
alization and solution of aircraft conflict situations, developed at EUROCONTROL Experimental
Centre as part of the Programme for Harmonised ATM Research in EUROCONTROL (PHARE)
project in 1994 [7] and has been largely used since then, e.g. to assess its applicability to oceanic
control [8].
Other DSTs have been tested with ATCOs in other simulated ATM environments for many flight
situations in [9, 10, 11] and in special for en route flights where results of interest go back to the
work of Picardi [12] in 1998.
Work on interactive, human-in-the-loop simulations has been done by Brennan et. al. [13] and
with the partnership of several important entities in the ATM world, namely EUROCONTROL [14]
in 2005 and National Aeronautics and Space Administration (NASA) [15] in 2011.
The human side of automation, the effects to performance and mental workload of ATCOs have
gained interest in the past years since many of the developed DSTs are failing their purposes:
diminish controllers’ workload. There are important studies on that subject performed by Wickens
[16] in 2000 and Major et. al.[17] in 2004. Parasuraman and Metzger [18] in 2005 examine
and compare the performance of controllers, under conditions of shared decision making, in the
presence of both perfect and imperfect automation tools while Sanchez, Krumbholz and Silva [19]
in 2010 discuss what shall be the role of the controllers in the Next Generation Air Transportation
System (NextGen).

3
1.4 Thesis contributions
This thesis contributes to the area of ATC automation, by evaluating a DST for en route con-
trollers through the integration in a simulated ATM environment.
Also, and taking into account the specific problem of oceanic airspace as a case study, a pilot
test with two virtual ATCOs was conducted during the 11th of October 2014 in IST in order to eval-
uate the developed system. The level of controllers’ workload while controlling with and without
the DST and their acceptance regarding the plug-in interface and DST functioning were inquired.

1.5 Thesis outline

The present thesis is organized as follows:

• Chapter 2: System Architecture

This chapter introduces the DST that was previously made, its functionalities, the assump-
tions that were made so as to define the simulation framework as well as the verified simu-
lation results.
Next, the interaction between the plug-in made as part of this thesis and the DST is pre-
sented. The areas where improvements were made or limitations were found – and there-
fore demand for workarounds emerged – in the DST are also discussed.

• Chapter 3: Simulation Environment and Plug-in Description

Herein, the chosen simulation environment as well as the plug-in’s interface and main rou-
tines are presented. The ideal connection between plug-in and DST is also discussed fur-
ther in this chapter.

• Chapter 4: Simulation and Results

The parameters needed to establish the simulation environment and the designed traffic
generation routines are herein presented.
Simulations carried out with the ATCOs and its results are laid out in this chapter as well.

• Chapter 5: Conclusions
In this last chapter the main conclusions coupled with suggestions for future work are dis-
cussed.

• Annex A: ATCOs Template Survey

Here, the drawn up survey used to establish the controllers opinions about the experiments’
validity is depicted.

• Annex B: ATCOs Answered Surveys

In this annex, the surveys, as filled by the ATCOs present in the trials, are presented.

4
Chapter 2

System Architecture

In this chapter we will describe the DST’s way of working in section 2.1, in a brief manner but
not so brief so as to allow readers to understand what is behind this thesis and the reasons that
led us into doing it.
It will also be pointed out which were the areas where margin for improvements was found
and the result that came from that finding, which can be one of the two following: some areas
that could and were improved and others that could not, thus standing as limitations and where
workarounds had to be found. Both those areas, as well as the communication between the
plug-in and the DST are discussed in section 2.2.
In the end of section 2.2, an encountered limitation to the thesis hindering the interactive part
of this work is discussed in detail.

2.1 DST description

The referred DST is the result of a MSc thesis made at IST in 2013 by Francisco Freitas,
supervised by Professors Rodrigo Ventura and Miguel Barão and is going to be described within
in this section.

2.1.1 Trajectory prediction routine

In order to detect future possible conflicts between aircraft, a routine that simulated their fu-
ture trajectories was necessary. Thus, an algorithm that uses built-in information from the Base
of Aircraft Data (BADA) – developed and maintained by EUROCONTROL – that gives precise
information about each aircraft’s performance model was calculated.
The algorithm uses spherical coordinates with quaternion algebra (see Chapter 2 of [4] for more
information on the quaternions) to account for the curvature of the Earth and so that the aircraft
constantly adjusts its heading angle in order to follow a Great Circle path between waypoints.
When it comes to dealing with unpredictable factors, the trajectory prediction algorithm takes
into account the uncertainty that wind causes on the ground speed and therefore on the Estimated
Time of Arrival (ETA) at waypoints. Wind is modeled assuming a Gaussian distribution.

5
2.1.2 Conflict detection and resolution routine
Conflict Detection and Resolution (CD&R) algorithm’s – which constantly uses the trajectory
prediction algorithm mentioned before – function is to find the global set of plans that solve a
traffic scenario i.e. that allow the completion of the simulation of that traffic scenario within a given
time window without any conflicts happening. The detection of conflicts is done by analysing at
any given moment the horizontal and vertical separation minima for each pair of aircraft in the
traffic scenario. If both are being violated, the aircraft-pair is assumed to be conflicting.
Every conflict-free plan is further scrutinized by running a robustness check consisting of a
Monte Carlo simulation1 with random wind as the uncertainty model.

2.1.2.1 Cost function

In order to evaluate and rank all the found plans, and thus allowing the best one (optimal
solution) to be presented to the user, a cost function was constructed. Taking into account both
the controller’s workload and the concept of efficiency2 , the chosen criteria to try and lower were:
• Number of instructions, N
Including N, the total amount of instructions that are issued by an ATCO within a given
time window, in the cost function serves the purpose of keeping the ATCO’s workload at an
acceptable level.

• Deviation cost, D
So as to minimize the distance flown by aircraft in other FL than the Requested Flight Level
(RFL) and thus maxime efficiency, vertical deviation from the Filed Flight Plan (FFP) was
measured and included in the cost function. Cost D depends on the distance between
waypoints where the instructions take place and on the vertical distance between the RFL
and the flown FL. E.g. figure 2.1 – taken and modified from [4] – where the blue line indicates
the trajectory requested in the FFP and the red line indicates the trajectory change that is
ordered by the CD&R algorithm and that transforms the FFP in a different, Current Flight
Plan (CFP). The grey area corresponds to the deviation integral – cost D is the sum of all
deviation integrals in a given solution – that is essentially the multiplication of the distance
between waypoints 43N020W and 43N030W by the difference between the RFL and the
flown FL (1000 ft in the example of figure 2.1).
Finally, the chosen cost function was:

f = λN N + λD D (2.1)

where λN and λD are weight coefficients. These parameters may be adjusted to benefit one of
the criteria over the other: specifying λN  λD causes the CD&R algorithm to instruct aircraft to
fly as closely to their FFP as possible, no matter how many instructions it takes; setting λN  λD
causes the algorithm to choose the solutions with as few instructions as possible, neglecting
vertical deviation from the RFLs.
1A computerized mathematical technique used to assess the impact risk of every possible outcome, allowing for better
decision making under uncertainty.
2 Efficiency is a measure of how closely an aircraft flies its designated flight plan, as defined by Krozel et. al in [20].

6
 Figure 2.1: Deviation integral illustration

2.1.2.2 Combinatorial optimization

In the interest of reducing the computational time while still finding the optimal solution, branch-
and-bound algorithm with a depth-first configuration was used. This search algorithm is complete
since it always finds a solution, as long as at least one exists.
The search method receives the traffic scenario file, the upper bounds that restrict criteria N
λN
and D – Nmax and Dmax respectively – and the criteria weight ratio λD
and outputs the optimal
plan for that weight ratio. The way in which Nmax and Dmax restrictions are generated is going to
be explained further in this subsection (subsubsection 2.1.2.3).
Starting at the beginning of the simulation, the search algorithm advances in time and when-
ever a flight passes by some route waypoint a node with several branches, corresponding to the
possible FLs where the aircraft can be allocated, is generated. With the help of the cost function
introduced in equation (2.1), the branch with lower cost is expanded and the instruction result-
ing from that branch is used to predict the trajectory of the aircraft between its current and next
waypoints.
A conflict detection is then executed in the calculated trajectories between the current node
and the next node. If a conflict is detected between two aircraft, the algorithm analyzes the stack
of nodes until it finds one referring those aircraft, resuming the search at that point. Else, the
algorithm checks to see if the current node is a terminal node – a terminal node (or solution plan)
is found when the simulation time window limit is reached or when every aircraft has already
abandoned the controlled airspace – and if so, a robustness check is carried out.
If a conflict is detected by the robustness check, the algorithm back jumps to a node involving
one of the aircraft present in the conflict and if not, the terminal node is considered a solution to
the traffic scenario that was inputted. After the first solution plan, upper bounds for Nmax and
Dmax are available, and may be used to prune branches, diminishing the computational time –
e.g. see subsubsection 2.1.2.3.

7
2.1.2.3 Interactive solution

At this phase, with two criteria to try and lower, the concept of optimal solution for a given
problem vanished since a solution might minimize one criteria but not the other. Instead, Pareto
optimal solutions (also known as Pareto front) came into place and a strategy regarding how these
solutions were calculated had to be chosen. Between the following three categories of strategies,
that differ on how they calculate the Pareto front and on how much the user has to be involved: a
priori methods, a posteriori methods and interactive methods – the last one was chosen.
In the interactive approach, the algorithm alternates between phases of calculation and phases
of interaction with the user, allowing him to participate in the optimization process by answering
some algorithm’s queries. The main advantages of this approach are that, unlike the a posteriori
one, it avoids the calculation of the whole Pareto front, thus saving both time and memory, and
that it allows the user to set his preferences based on some knowledge about the Pareto front,
unlike the a priori approaches. On the other hand, the main flaw of the interactive methods is that
when the user states his preferences, his knowing about the Pareto front might not be sufficiently
broad, which can ultimately lead to settling for solutions that are local bests and far from global
bests.
To better understand how the Pareto front equipped with the interactive approach works, let us
λN
observe figure 2.2, taken from [4] ( λD
stays the same in the four sub-figures).
So at the beginning, Nmax and Dmax are initialized as infinite since no restrictions exist yet and
the vector that saves the Pareto front solutions, ParetoList is initialized as empty. The branch-
and-bound algorithm starts working and assuming that the given scenario is solvable, a particular
solution S1 with N1 instructions and D1 deviation cost is found and added to the ParetoList –
figure 2.2a.
At this point the user is confronted with the first decision: either accept the solution S1 or request
the calculation of more inside region I (where N < N1 ) or inside region II (where D < D1 ),
both depicted in figure 2.2b. Note that in this figure (as well as in figures 2.2c and 2.2d) red
areas correspond to the Pruned solutions, where solutions have more N and more D than the
previously found solutions and thus deterring them from belonging to the Pareto front. The grey
regions represent areas where no solutions to the scenario can be found because they would
have less N and less D than some solution in the Pareto front, condition that would guarantee
that they would have been returned by the algorithm instead. E.g. if there was any solution in the
grey area of figure 2.2b, it would have N < N1 and D < D1 which would cause the return of that
same solution instead of S1 .
Supposing now that the user rejects the given solution S1 and requests another with N smaller
than N1 – region I of figure 2.2b. A second Pareto front solution S2 is then found – figure 2.2c –
and presented to the user. Now, there are three possible regions to look out for more Pareto front
solutions: region I (where N < N2 ), region II (where D < D2 and N < N1 ) and region III (where
D < D1 ).
Presuming that the user is not yet happy with the solution and wants to explore region II now,
takes us to a solution S3 – figure 2.2d. At this point, the user is happy with the resulting solution
and accepts it, which causes the interactive algorithm to exit.

8
 (a) First found solution -S1 (b) First decision to be taken by the ATCO

(c) Second found solution - S2 (d) Third found solution - S3

Figure 2.2: Pareto optimal set calculation

9
2.1.3 Assumptions
Some assumptions were made in order to define the simulation framework. They were:

• Uncertainty in trajectory prediction routine

Since in en route oceanic operating outside radar coverage, the lack of information requires
the conflict-avoiding maneuvers to be taken well ahead of time and that the horizontal sep-
aration is increased a lot, uncertainty causes that only affect the instruction issuing and
maneuver execution are assumed to be inexistent e.g. high workload, radio communication
degradation, aircraft pilot reaction time.
Therefore, and despite a real ATC environment having countless factors that can cause
unpredictable effects, the wind was the only cause for uncertainty that was taken into con-
sideration when doing the trajectory prediction of aircraft.

• Airspace
The special case of oceanic airspace, where conventional ATC is still used due to the lack of
radar coverage, was used as a case study and the chosen FIR where the simulations were
to take place was Santa Maria (the International Civil Air Navigation (ICAO) code for Santa
Maria FIR is LPPO and that is how it is going to be referred from this point on).
As a simplification, LPPO’s radar was ignored and thus aircraft flying inside LPPO were
assumed to be outside radar coverage. Also, since the DST is focused on the cruise phase
of flights, Santa Maria terminal area was neglected.

• Minimum and maximum FL

In LPPO, as in most of the world-wide ATC FIRs, the Reduced Vertical Separation Minimum
(RVSM) rules are applied and so the minimum FL where the DST allocates aircraft was
FL290 (29000 ft).
As of the maximum FL, it depends on each aircraft’s service ceiling3 plus a tolerance that
is discussed next. No matter what, that maximum FL for aircraft allocation was never to
exceed the RVSM’s maximum – FL410.

• Tolerance for maximum FL

In general, the RFLs in the FFP are respected by ATCOs and are not exceeded. However,
in certain cases, the pilots may accept or even request flying at higher altitudes than the
RFL e.g. when take-off weight was lower than expected.
DST’s way of dealing with this was to set a tolerance of FLs in which the aircraft could be
allocated past its RFL. E.g. if the RFL of an aircraft is FL380 and the tolerance is set to 2,
the maximum FL where the aircraft could be allocated would be FL400.
The used tolerance was of 1 level.

• Type of instructions
Because of the lack of radar coverage in most oceanic airspace and so of the possibility
to access the aircraft’s position in real-time, horizontal and speed change maneuvers are
3 The altitude at which the aircraft is unable to produce a given rate of climb (typically of 100 ft per minute).

10
 rarely used by ATCOs as they are not effective when comparing to continental radar ATC.
On the other hand, vertical maneuvers, backed with the modern aircraft autopilot’s ability to
measure and maintain a precise altitude, provide a safe way to ensure separation, even with
some horizontal position uncertainty.
Thus, most detected conflicts in oceanic airspace are solved by ATCOs resorting to vertical
instructions and hence the developed DST utilizes vertical instructions only when solving
conflicts.

• Period for instruction issuing

In oceanic ATC, besides the mandatory position reports that have to be done by pilots, the
communications between ATC and pilots are infrequent. Thus, it is common practice in
oceanic control to issue instructions to aircraft only when they pass route waypoints instead
of at random route points.
The DST was made so as to comply with that common practice.

• Separation minima
Since the chosen portion of the airspace was one where the RSVM rules apply, the chosen
vertical separation minima used to detect conflicts in the CD&R algorithm, in accordance to
the RSVM rules – present in [21] – was:
– Vertical separation minimum: 1000 ft
On the other hand, it was demonstrated in the implementation plan present in [22] that
the standard horizontal separation of 50 NM (nautical miles), – in accordance with PANS
ATM Doc. 444, [23] – already in use in most North Atlantic (NAT) airspace, could be safely
implemented in LPPO. The used horizontal separation minima was therefore:
– Horizontal separation minimum: 50 NM;

• Aircraft models
All simulated aircraft were Airbus 320 models. The reason being that it was the only model
for which the Flight Management System (FMS) gain parameters were devised. The FMS
gains are needed to correctly simulate the trajectory prediction of each aircraft.

2.1.4 Results
Running time trun is important when analysing the effectiveness of the DST and thus it was
studied through a test with multiple simulations with random traffic scenarios. Its evolution as a
function of the number of flights NF is depicted in figure 2.3, taken from [4], where one can see
that it verifies an exponential increase. Keeping in mind that the trun is that of searching the
optimal solution, the results seen in figure 2.3 are satisfactory. More on this subject is going to be
discussed in subsection 2.2.3.
As for the running time, memory usage was analysed by running several simulations with ran-
dom traffic scenarios for each NF, and it was shown that a linear increase was verified in memory
usage. Memory was therefore not a concern.

11
 Figure 2.3: Mean values for trun as a function of NF

A high variety of simulations with different traffic density and complexity were conducted and
the DST proved its robustness. The results were considered very good and the DST seemed
ready for the next step, i.e. test it with ATCOs.

2.2 Plug-in communication with the DST

2.2.1 Input/Output analysis

A high level representation of the communication between the plug-in that was made as part of
this thesis and the DST can be seen in figure 2.4, where one can notice that the outputs of the
plug-in (and inputs of the DST) are:

1. Scenario: it provides the DST with the information about the current time, the total number

Figure 2.4: Scheme of the communication between the plug-in and the DST

12
 Callsign IBE201
Departure LEMD
Destination SPIM
Model A320
Airspeed 410
Route ELVAR,IRKID,33N20W,28N30W,23N40W,15N50W,
Flight Profile 360,360,360,360,360,360,
State Inside
Last Waypoint 33N20W
Reported Time 1353
Last FL 360
Table 2.1: Example of flight plan for aircraft that is already inside the LPPO

of aircraft present in the actual scenario as well as the flight plans for every aircraft;

λN
2. λD
: the criteria weight ratio. It remains constant during a simulation;

3. N max : restriction introduced to limit the criteria N;

4. Dmax : restriction introduced to limit the criteria D.

The flight plans that are contained in the scenario file are structures constituted by the following
fields: Callsign (a string that is unique for each flight and that identifies it), Departure and Des-
tination (ICAO codes for departure and destination airports respectively), Model (model of the
aircraft), Airspeed (the requested cruise airspeed in knots), Route (the sequence of waypoints
to be followed by the aircraft), Flight Profile (the RFL for each route segment) and the State (the
current state of the aircraft that could either be outside the oceanic FIR and Planned to enter it or
already Inside the oceanic FIR) followed by the ETE (Estimated Time of Entrance in the oceanic
FIR) if Planned or by the Last Waypoint (last waypoint where the aircraft reported), the Report
Time (time when the aircraft gave the last report) and the Last FL (the FL of the aircraft when the
last report was made) if Inside. E.g. see table 2.1 to see an example of a flight plan of an aircraft
that is already inside the LPPO.
On the other hand, the input of the plug-in (and output of the DST), referred as Solution in
figure 2.4, is the set of instructions that solve the inputted scenario with the given restrictions and
that are going to be presented to the ATCO by the plug-in’s interface.

2.2.2 Simulated time to real-time

The feeding of the DST that we see in figure 2.4 was previously done only once in the entire
simulation as the DST was designed to operate in simulated time, and hence in an offline manner
only, and to run only one time while solving each scenario. What the DST did was: receive the
scenario file as well as the restrictions, simulate internally the aircraft’s trajectories throughout the
previously defined duration of the simulation and in the end output the solution of that inputted
scenario (if its resolution was possible). That is the reason why the flight plans and the number of
aircraft in the scenario file were set to be immutable throughout the duration of a DST’s simulation.

13
 In our case however, the simulation is in real-time and as the conditions of the simulation are
often changing (e.g. some aircraft arrives at its next waypoint 10 minutes past the prediction time)
new calls to the DST are needed every time some aircraft arrives at its next waypoint or each time
a new aircraft enters the simulation. Thus, the connection between plug-in and DST is necessary
dozens of times during a session.
The solution for this conversion from offline to real-time was pretty straight-forward, just change
the State and its derivatives (ETE for Planned aircraft and Last Waypoint,Reported Time and Last
FL for Inside aircraft) as simulation progresses and aircraft get to their next waypoints and add the
flight plan of newly simulated aircraft. We will discuss in subsection 2.2.4 the limitation that arose
from this new way of using the DST.

2.2.3 Improvements
In order to better interact with the plug-in and so that the experience for the ATCOs was the
most alike real ATC as possible, some improvements were made to the DST’s algorithms:

• Change in simulation start time

Before, the simulation time was set to be at 0800Z (Zulu time4 ). When integrated with a
simulated ATC system, that parameter need to be variable and thus, the DST was changed
to receive every possible start time from the plug-in.

• FMS of other aircraft

As mentioned before, Airbus A320 aircraft model was the only one considered in the sim-
ulation. As the replication as much as possible of real ATC system is the objective, having
only one aircraft model detaches some credibility of the scenario files and thus efforts were
made in order to have a wider variety of functional aircraft models.
Common models for aircraft flying oceanic airspace were considered and 10 more of these
models were added – by devising FMS files for each one. A total of 11 aircraft models
(including the A320) were used in the simulations which led to more diversified scenario
files.

• Anytime algorithm
During the testing phase of the DST, as one can see in figure 2.3, the trun when searching
for an optimal solution was found to be quite big in some cases. E.g. for a NF of 40 the
mean value for trun is approximately 630 seconds (10 minutes and 30 seconds). Test the
DST with ATCOs and allow for that kind of wait for a solution is inconceivable since a real
controlled environment can change considerably during that waiting period.
The solution to this problem consisted on applying an anytime algorithm to the DST. Each
loop of the DST’s solution finding would be tested to check if a pre-defined trun was already
reached. If so, and if there was one or more found solutions (non-optimal ones), the algo-
rithm forced the return of the last found (and better for that matter) solution. Else, if trun
was passed but there were not solutions yet, the DST’s solution finding kept running until a
solution was found, moment where that same solution was returned.
4 Zulu time is used in the military and in navigation as a term for Coordinated Universal Time (UTC).

14
 The adopted strategy allows to combine the better of two worlds: first take advantage of the
better optimal solution finding strategy while an acceptable trun is not reached; then adopt
a slightly worse non-optimal solution finding strategy while not allowing ludicrous trun to be
reached and therefore allowing the ATCO testing to take place.

• Other
Many other minor alterations were done in order to correct some things or to adapt the DST
to the plug-in. E.g. the border points connecting Piarco FIR and LPPO did not exist so they
were added in the appropriate routine; the visual part of every DST’s algorithm was removed
since it would be of no use to the C++ user, also reducing the running time in a small, but
important, amount.

2.2.4 Limitations and solutions

Some limitations were encountered while communicating with the DST. While the DST did well
when tested with an offline environment, some adjustments had to be done in order to integrate it
with a simulated environment.
As discussed in subsection 2.2.2, the conversion from simulated time to real-time was overcame
easily by changing the scenario files throughout the simulation and calling the DST again and
again when necessary. However, it was noticed that some of the instructions that were given in a
previous call to the DST were not being given anymore when a new call was placed, even when
the conditions of the simulation changed only in accordance to the planned ones.
For better understanding of the problem and why this is a limitation for a real-time simulated
environment, let us take a look at figure 2.5 where we can see an example that takes place inside
LPPO. There, an aircraft with callsign KLM113 that is currently on waypoint PASAS and travels
according to the following flight plan (only the remaining and inside LPPO flight plan is showed):
40N20W 35N25W 31N30W 24N40W, and another aircraft that travels in the opposite direction.
This last one has callsign BER341 and after its current waypoint, 28N30W, it is going to pass
through the following waypoints: 35N25W 40N20W GONAN. Both are traveling at FL360.
Looking again at figure 2.5, we can see that the flight with callsign KLM113 is expected at its
next waypoint, 40N20W, at 1205Z and at its third waypoint inside LPPO, 35N25W, at 1250Z. On
the other hand, flight BER341 is expected at its next waypoint, 35N25W at 1220Z and at the
waypoint after that, 40N20W, at 1305Z.
Thus, the aircraft share the segment 35N25W-40N20W (or 40N20W-35N25W if seen by the
KLM113 flight referential) and by looking at the ETAs we can see that when the BER341 flight
enters that segment, KLM113 is already there. Therefore there is going to exist a conflict be-
tween these aircraft and a call to the DST shows that in order to solve this simple scenario, two
instructions, both to BER341, need to be made: the first telling BER341 to descend one FL to
FL350 when at waypoint 35N25W and the second, after the conflict has been avoided in way-
point 40N20W, telling that same aircraft to climb one FL to its original RFL. In our plug-in, as
explained before, a new call to the DST is needed each time an aircraft crosses a waypoint. So,
in order for everything to be correct, when BER341 passes waypoint 35N25W and a new call to
the DST is made, an instruction (the second one of the previous call) that takes the aircraft to its
RFL should be given. Unfortunately that does not happen.

15
 Figure 2.5: Scenario demonstrating a conflict between two aircraft flying inside LPPO

16
 Before After
BER341 -
EDDL -
SKBO -
A320 -
410 -
28N30W,35N25W,40N20W,GONAN -
360,360,360,360, 360,350,350,360,
Inside -
1141 -
28N30W -
360 350
Table 2.2: Differences between the call to the DST, before and after the solution was applied. The “-”
means that no change was made in that field

That means that, the third time a call to the DST (third time and not second because the KLM113
passes first at waypoint 40N20W, generating a new call to the DST. This new and second call has
the same solution as the first one) is made, the DST just assumes that the RFL of the BER341
aircraft is FL350 instead of FL360 and chooses not to “waste” any more instructions on that
aircraft. The DST’s way of thinking is: if the aircraft can stay in its current flight level and not
conflict with any other aircraft, why waste any other instruction on it?
In order to solve this it was noticed that, to the DST’s eyes, there are two kinds of instructions:
the ones that solve conflicts and the ones that take the aircraft to their RFL. The above described
problem only took place in the second type of instructions since while the conflict is present the
first type of instructions will keep on being given. After realizing that, it was a matter of making
the plug-in differentiate between the two kinds of instructions. So, when the plug-in notices that
one of the instructions is of that type, it makes some changes to the supposedly unchangeable
flight plan that passes to the DST in order to make the algorithm realize the second instruction is
necessary – see table 2.2 where the flight profile and the FL of the report from the last waypoint
28N30W were modified in order to produce the wanted results.
Another limitation of the DST was that before everything about the scenario was known and the
number of aircraft present in it did not change throughout the duration of the simulation. In ours
(and in real ATC), however, often there are airplanes that only enter the controlled FIR after some
amount of time. Therefore, one of those delayed airplanes can have a conflict that is impossible
to solve with one the pre-existing aircraft inside the FIR. To solve this, only traffic scenario files
where this does not happen were considered. Solve this limitation in the DST falls behind the
purpose of this thesis and it is simply left as a suggestion for future work.

2.2.5 Impossibility of using the interactive solution

When tests to evaluate the DST-plug-in connection began, it was noticed that every time a
restriction in criteria N or D was introduced, the algorithm exited abruptly referring to a coding
error in the DST’s interactive algorithm. This bug, if not solved, would impose a major limitation to
this thesis, ruling out completely the use of the interactive solution that would be one of the most

17
interesting aspects to evaluate the human and DST interaction.
Thus, attempts to resolve the bug were extensively made by me and by the own creator of
the DST, all having the same result: insuccess. After some time trying to solve the problem, it
was decided that no more time should be invested in solving the bug and instead it would stand
as a limitation for this thesis while the reasons for that were: the objectives of this thesis did
not contemplate solving other thesis’ code; the continuation of the bug solving attempt would
compromise even more the appropriate time window to finish the thesis.
So, the scheme of communication between the plug-in and the DST depicted in figure 2.4 had
to be simplified to the one in figure 2.6 where one can observe that the feeding of restrictions –
for both criteria N and D – to the DST is no longer made.

Figure 2.6: New scheme of the communication between the plug-in and the DST

18
Chapter 3

Simulation Environment and Plug-in

Description
Within this chapter, the chosen simulation environment for integration of the DST is briefly
discussed in section 3.1. Some of its not so obvious capacities are also exposed.
Then, in section 3.2, an overview about the designed plug-in will be made. The objectives,
programming languages and strategies used to achieve the best possible plug-in interaction with
the DST are explained. Next, a concise explanation about the plug-in’s routines and their relations
to one another is made. The plug-in’s interface will also be presented and finally a problem
regarding the plug-in-DST connection periodicity is discussed in the last subsection.
In the last section, 3.3, a supplementary window that gives information about waypoint re-
ports and that was constructed in order to better approximate the simulations to the conventional
oceanic control is presented.

3.1 Simulation environment

There are many ATM simulation tools currently available. One that is considered excellent,
freely available and largely used by virtual ATC communities – e.g. by the biggest, Virtual Air
Traffic Simulation Network (VATSIM) – is Euroscope. It is also the one (version 3.1d) that has
been chosen in this thesis since it is very much alike the one ATC uses nowadays.
Within this section, the interface of Euroscope will be shown and some of its functionalities are
going to be discussed.

3.1.1 Interface
Figure 3.1 shows a print screen of Euroscope’s environment while figure 3.2 shows a zoom in
of that previous one to show an area of interest in more detail. In red we have the limits of LPPO,
in yellow the geography of Azores islands and in grey the TAGs of the multiple aircraft present
in this specific simulation. TAGs show the controller the relevant and available information about
the flight situation and they can be Untagged and show only the squawk code and the FL of the
aircraft or Detailed and show every piece of information that we want like the callsign, the aircraft
type, the destination, the cleared FL, etc. An example for each TAG can be observed in figure
3.2, where an example for an Untagged flight is the one with squawk code 4237 and FL390 and
an example for a Detailed one is aircraft with callsign IBE6464 in the same figure.

19
 Figure 3.1: Print screen of the simulation environment Euroscope

At the top of the window, there are multiple options for the simulation as well as for the Eu-
roscope graphics and at the bottom the chat box used to receive messages from the VATSIM
server – irrelevant for our purposes – as well as the command line, where ATCOs can make use
of important commands, can be seen.

3.1.2 Functionalities
EuroScope is a state-of-the-art ATC client software for virtual ATC enthusiasts that combines
features obtained from real life radar software and also from years of online controlling experience.
It features an innovative display and handling of controlled airspace and a built-in simulator for

Figure 3.2: Zoom in of figure 3.1 to show different aircraft in greater detail

20
training purposes and it is widely used by virtual ATCOs for its innumerous functionalities and
display, which allow for as real as it gets controlling over simulated aircraft.
Besides the many obvious functionalities that Euroscope has to offer, some more hidden need
to be highlighted for their relevance in the scope of this thesis:

• Command line

The command line seen previously in figure 3.1 has many functions where the three most
important for ATCOs in our case are: .find followed by a callsign to find a specific airplane
in the simulation, .distance followed by two objects – objects can be all aircraft, fixes, co-
ordinates, VHF Omnidirectional Range (VOR) stations and Non-directional Beacon (NDB)
radio towers present in the simulation – which gives the distance between those objects and
also pops the distance data in light yellow on top of the screen, constantly actualizing that
information – important to keep observing the distance of an aircraft to its next waypoint for
example – and .sep followed by two aircraft’s callsigns, which gives the closest point of their
converging paths and the estimated time to reach that point.

The two last functions can also be accessed by buttons that are present on top of Euro-
scope’s window.

• Trajectory prediction

Let us note in figure 3.2 the blue path that has origin in IBE6464 flight and intersects way-
points 37N20W and PORLI. That path is not normally presented in the radar screen, but
instead is a handy function of Euroscope which allows to see the aircraft trajectory and the
ETA to each waypoint of its future route. This function will be intensively used by ATCOs
testing the plug-in so as to keep track of the aircraft’s next waypoints as well as the estimated
times at which orders can be issued to them.

• Pilot minimum and maximum delay

The pilot minimum and maximum delay determines how fast the pilot will respond to an
order. For every order made in the simulation, the aircraft will respond and start following
it by random seconds of time between the minimum and the maximum value. By omission,
these parameters assume values of 12 and 17 seconds respectively seconds – values that
were measured by real-life controllers as average response time.

3.2 Plug-in description

3.2.1 Objectives

The objective of this plug-in was to integrate the DST from chapter 2 with the previously pre-
sented simulation environment Euroscope.
The plug-in would be designed so as to constantly feed the DST with flight plans and up-to-date
information about aircraft’s reports and to have an interface allowing the solutions from the DST
to be presented to the ATCOs.

21
 So as to fulfill the above mentioned requirements, a child window – interface-wise – of Euro-
scope was created and a bridge between plug-in and DST was constructed to allow the connection
between the two platforms, i.e. plug-in and DST.

3.2.2 Computational languages

Euroscope 3.1d is programmed in C++ using MFC. That is why, in order to develop a Dynamic-
Link Library (DLL) plug-in that could be loaded into any computer running Euroscope, Visual C++
in Microsoft Visual Studio 2012 was chosen.
Python 2.7.4 was also extensively used to make the discussed alterations in the DST – subsec-
tion 2.2.3 in chapter 2 – and to make the bridge routine Bridge.py that called the multiple DST’s
algorithms and properly handled the responses from them.
Since the plug-in was going to be constructed in C++ and the language in which the DST’s algo-
rithms had been written was Python, some solutions to guarantee a proper connection between
the languages were considered and studied: Cython1 , protocol buffers2 , simple sockets, ØMQ3
and embedding Python in C++ using the Python/C Application Programming Interface (API)4 (not
be confused with extending Python. They are similar in some aspects but while in the first the
main program is in a different language, while extending, the main program of the application is
still the Python interpreter).
The latter was chosen. It works by embedding the Python interpreter in the plug-in and using
the Python/C API to run Python scripts inside the plug-in. This practice of using built-in scripting
languages – Python in this case – has been largely at use for example in game engines where
the graphics and low-level artificial intelligence are written in C++ while the scripts – in another
language – control high-level scripted events, map generation, etc.
Some of the reasons for choosing embedding over other plausible options were:

1. Fairly intuitive, unlike for example protocol buffers;

2. The feedback from the users was extremely satisfactory;

3. It involved an API made by Python specially for that matter, which is always good since
Python reference manuals are generally very thorough;

4. Python scripts do not need to be opened unlike for the sockets strategies;

5. There is no need for Python to be installed in the used computer – portability;

6. Once Python interpreter is initialized and the modules are loaded for the first time (≈10
seconds of duration) the connection between the two languages is achieved really fast,
almost instantly (measured at 0.0093 milliseconds).

1 http://cython.org/
2 https://code.google.com/p/protobuf/
3 http://zeromq.org/
4 Reference manual: https://docs.python.org/2/c-api/

22
3.2.3 Routines
Before getting into discussing the plug-in’s main functions, there is need to describe in detail a
global vector of structures CFP_list used to keep all the necessary information about every active
aircraft in the simulation available to every function of the plug-in. Each structure of CFP_list has
the following fields:

• Callsign: the callsign of the aircraft;

• Origin_airport: the ICAO code for the origin airport;

• Destination_airport: the ICAO code for the arrival airport;

• Aircraft_model: model of the aircraft in question;

• True_airspeed: the current true airspeed of the aircraft;

• Route_list: vector with all the route waypoints that are filled in the initial flight plan;

• FL_list: list of FLs of the aircraft at each traveled waypoint of its route. Every time the
aircraft arrives at a new waypoint the vector is increased in size by one unit with the FL at
that waypoint;

• LastWP: an integer keeping the position in the Route_list of the last waypoint crossed by
the aircraft;

• Hour_lastWP: the hour when the last waypoint was crossed;

• NextWP: an integer with the position in Route_list of the next waypoint that the aircraft will
pass. It is basically LastW P + 1;

• Hour _nextWP: the ETA at the next waypoint;

• Coord_nextWP: the coordinates of the next waypoint;

• State: a boolean value to check if the aircraft was inside or outside the FIR at its last way-
point;

• EntranceWP: an integer holding the position in Route_list of the entry waypoint in the FIR;

• ExitWP: an integer keeping the position in Route_list of the exit waypoint from the FIR.

As for the routines: the main function of the plug-in OnRefresh() refreshes the radar screen and
its contents every second and multiple times per second if some window object is being dragged
around. Within this function various important routines are called:

• Load_WPs() reads a text file containing the complete list of fixes of the FIR in question and
defines a global map5 for future quick finding, WP_map. It is by using this list that func-
tions Find_EntranceWP() and Find_ExitWP() which generate EntranceWP and ExitWP
respectively are called for each aircraft.
5A C++ map class. http://msdn.microsoft.com/en-us/library/s44w4h2s.aspx

23
 • Check_new_airplanes() is used to loop over all the planes available in the simulation, com-
paring the results of that looping with a pre-existing list of active and already finished from
the simulation aircraft, AllAircraft_list. If any aircraft appearing in the loop is new to the
simulation i.e. if it is not in AllAircraft_list, it is added to both CFP_list and AllAircraft_list.

• Check_distances() uses the Coord_nextWP field of CFP_list to calculate the distance of

aircraft from its current coordinates to its NextWP. If this distance is inferior to 1 NM, the
aircraft is assumed to have arrived at its NextWP and thus the following fields are updated:
FL_list, LastWP, Hour_lastWP, NextWP, Hour_nextWP, Coord_nextWP and State if the air-
plane enters or exits the FIR. In case the aircraft leaves the FIR – condition checked if
N extW P = ExitW P – it is erased from CFP_list.

• AddScreenObject() defines all clickable areas on the radar screen. Areas for each button,
for the whole window, etc are all herein declared.

• DrawWindow() is responsible for checking the desired window state i.e. minimized, maxi-
mized, loading solutions, presenting the set of solutions, etc and for drawing the appropriate
contents of the plug-in’s window for each state.

Outside the scope of the main function there are other important functions such as Move-
ScreenObject() and ClickScreenObject(), used whenever the user moves or clicks, respectively,
any object previously defined in AddScreenObject() function. These two functions are constantly
on the listening for an user action. Another important routine responsible for the communication
with the DST is Python_embed().
MoveScreenObject() has the functions governing the movement of the plug-in’s window and of
the plug-in’s scrollbar. For the latter, its thumb height and current position used in DrawWindow()
are also herein calculated.
On the other hand, in ClickScreenObject() there are the functions constructed for each but-
ton. The one for “Start” button is responsible for making the first call to the DST’s algorithm via
Python_embed(). Since the algorithm does not instantly return a solution and instead has often
a running time in the order of the minute, threading is necessary to avoid plug-in freezes while
the algorithm is finding solutions. Thus, every new call made to Python_embed() is achieved by
starting a new worker thread that runs concurrently with the main thread.
Python_embed() in its turn, is the function responsible for the communication between the
C++ plug-in and the Python files. It first initializes the Python interpreter – only needed for the
first time – and holds the Global Interpreter Lock (GIL)6 .Then, it transforms the current contents
of CPF_list into a string correctly formatted so as to be read by the DST, resorting to a function
constructed for that purpose, Vectorcontents2string(). After that, the string along with the rest
of the values that need to be passed to the DST are transformed in a tuple and send to Python’s
routine Bridge.py that handles the calling of the different DST’s algorithms. After some time, the
response from the DST is received, treated properly in Bridge.py and sent to Python_embed().
After analysing the DST’s solution, Python_embed() shares the information with the other plug-
in’s functions in the form of a vector Instruction_list, making it available to be used for example
in DrawWindow().
6 Mutex that prevents multiple native threads from executing Python bytecodes at once.

24
 For better visualization of the above discussed a high level flowchart depicting the most impor-
tant relations between the main routines is shown in figure 3.3.

Figure 3.3: Flowchart of the most important plug-in’s routines

In this figure, blue lines symbolize the path that has to be traveled to make a new call to the
DST. First, either Check_new_airplanes() or Check_distance() update vector FP_list. Then,
this vector is called by Vectorcontents2string() within Python_embed() and the string is sent to
Python routine Bridge.py that is in charge of calling the DST’s algorithms.
In red, one can see the path between having found a solution and having it drew on the screen.
First the DST returns the solution to Bridge.py which signalizes Python_embed() that the so-
lution is ready to be transferred. Next, the solution is sent to Python_embed() which in turn
updates it in vector Instruction_list. Finally, DrawWindow() understands that there is up-to-date
solutions to be displayed and utilizes the last referred vector to do so.
The black lines simply make note that data available to click or move on the screen, ClickScreenOb-
ject() and MoveScreenObject() respectively, is constantly being provided by AddScreenOb-
ject().
The above discussed routines are called multiple times during a simulation session until finally,
when the user wants to terminate the current session and thus presses the close button, declared
in ClickScreenObject(), every global vector is emptied – except for the WP_Map that can be
reused in next sessions thus avoiding a new call to Load_WPs() – leaving the plug-in ready for
an upcoming session.

25
 Figure 3.4: Print screen of Euroscope with the plug-in loaded

3.2.4 Designed interface

One option to make the plug-in’s interface was to use the MFC classes that have default windows
almost completed. However since the objective was to have a child window with the same style as
the main and remaining child windows, everything needed to be done from scratch and by “hand”.
For that reason, and although it may appear easy to the eye of the non-programmer, most of the
moving functions as well as some of the buttons functions were pretty difficult to achieve.
The two created versions of the plug-in are presented below in this subsection. First, the
interactive version that was made as the primary goal for this work is presented, and then a
more simplistic version of that same interactive version is shown. This last one was forcibly made
due to the limitation found during the thesis making – discussed in subsection 2.2.5.

3.2.4.1 Interactive version

In figure 3.4, a part of Euroscope’s window with all the previously discussed elements and with
an extra one is presented: at the top-right corner with title “FL Changes List” there is the plug-in
window. This window is movable and in figure 3.5 we can observe one of these windows in more
detail.
Looking at that detailed image of the plug-in one can see multiple features that are hereafter
explained:

• 1: title bar with a brief description of the plug-in’s intention. It is also the only grabbing area
for when the user wants to move the window;

• 2: minimize/maximize button;

26
• 3: close button;

• 4: reject the current set of instructions and ask for another with less instructions than the
current one – the criteria N referenced in chapter 2 subsection 2.2.1;

• 5: reject the current set of instructions and ask for another with less deviation than the
current one – the criteria D referenced in subsection 2.2.1 of chapter 2;

• 6: undo button that allows the user to undo the actions and show the previous set of instruc-
tions. If undoing the previous action is not possible – more on this later – a bell sound is
played when the button is pressed;

• 7: display area of the plug-in where one of the following options is in use: the start button
(figure 3.6a), the set of instructions (figure 3.6b) or a message indicating that either the
scenario has no solution (figure3.6d), no conflicts were detected (figure 3.6c) or that any
other error was encountered. In case the message of figure 3.6d is being showed, it is
accompanied by the pair of aircraft precluding the resolution of the scenario with the current
set of conditions. This way, the ATCO can still solve a conflict via giving instructions in
non-standard positions i.e. not only after waypoints reports like the DST was intended to.

As for when the set of instructions is displayed, those instructions are ordered by time of
occurrence and the ones shown in yellow, instead of the regular white, indicate that the user
has already carried them out. In the specific case of figure 3.5 the set of instructions are in
display and each instruction is separated by the following fields:

– 7a: callsign of the aircraft in question;

– 7b: waypoint where the instruction shall take place and the predicted hour of arrival at
that waypoint;

– 7c: instruction, on whether the aircraft is supposed to descend or climb, followed by

the resulting FL of that instruction;

• 8: scrollbar, that only appears when the number of instructions is superior to a pre-defined
value and that has variable size depending on the total number of instructions.

27
 Figure 3.5: Interactive plug-in’s interface

Before making two extra considerations about the interface, it becomes important to define
cycle of instructions. A cycle of instructions is the amount of time when the current FP_list is
up-to-date and remains valid i.e. the interval between the last time any update was made –
if Check_new_airplanes() or Check_distances() changed something in the FP_list – and the
next time an update is going to take place. All set of instructions given and/or asked for during
this time belong in the same cycle of instructions.
With that said, the reason for undo button only allowing to go back to a certain point is unveiled.
Within a cycle of instructions, if the ATCO asked for 3 extra solutions, the undo button allows him
to go back to any of them but he cannot undo his actions until an older cycle of instructions (e.g.
by undoing 5 times) because every solution that might have been available there was going to be
outdated and would not be valid in the current air traffic situation.
Also, note in figure 3.5 that there are two instructions for aircraft AVA345: first descend to FL380
at waypoint 35N20W and then climb back to FL390 at waypoint 32N30W. However, the controller
will not have the opportunity to deliver those two instructions to the aircraft in the duration of a
cycle of instructions since, as mentioned before, in the aircraft’s next waypoint another call to the
DST is made and another set of instructions is presented – if the conditions of the simulation
change only accordingly to the predicted instructions changes, the second instruction (climb to
FL390 at 32N30W ) is then going to be given as the first instruction to aircraft AVA345.
Rather, future instructions are also showed in order to give controllers a correct idea about the
size of the current set of instructions. Also, it allows ATCOs to conceive a better mental image
about the future work that they will have if they adopt this or that DST’s advice.

28
 (a) Start button (b) Set of instructions

(c) Other messages: no conflicts detected (d) Other messages: impossible to solve a
given conflict

Figure 3.6: Interactive plug-in’s display area under different configurations

29
3.2.4.2 Non-interactive version

This second version of the plug-in is a simplistic version of the interactive version, obtained
through reverse engineering.
The resulting window from this practice is depicted in figure 3.7, where one can notice that in
comparison to the window in figure 3.6b differs on the absence of the three top buttons – as for
figures 3.6a, 3.6c and 3.6d the same occurs so there is no need for them to be hereby showed.

Figure 3.7: Non-interactive plug-in’s interface displaying a set of instructions

Thus, the only interaction with ATCOs – besides the obvious minimize/maximize and close
buttons – that is still achieved is the start button that allows users to define when to start the DST
help. From that point on no more interactions are made, and the ATCOs have to settle for the
suggested set of instructions.

3.2.5 Plug-in - DST connection periodicity

We have talked about the first time a call to the DST is made through Python_embed(). Now,
let us talk about the other hundred times per session that this communication is needed.
Ideally, a new call to Python_embed() was to be made when:

1. A new airplane entered the simulation;

2. An aircraft crossed some of its route’s waypoint.

and the information coming from those calls was to be displayed for a reasonable amount of time.
However, and even with the implementation of the anytime algorithm – subsection 2.2.3 of
chapter 2 – the DST running time was often impracticable. E.g. in a scenario with 30 aircraft
where the average time window having any aircraft crossing a waypoint was 2 minutes and the
DST’s average running time was 3 minutes, it was impracticable to call Python_embed() in every
situation of the two mentioned above because it would seldom present the solutions in the plug-
in’s window and rather the message “Finding solution”. In other words, it would spend more time
in discovering the solutions than in presenting them which is not of course the intention for a tool
that aids decision.
Three strategies to this problem were thought of:

30
 • Run Python_embed() in both the above stated conditions (1 and 2) but while the solutions
were being sought, the last solution found by the plug-in would be presented.

On the upside, this strategy would always present some solution to the controller but on the
downside, the presented solution could be outdated and worthless, causing the ATCO to
give instructions that should not(or could not) be given. Also, if the scenario file has many
aircraft, the frequent (if not permanent) DST calling would cause the plug-in to very heavy
memory-wise in everyday computers.

• Run Python_embed() only from time to time. No calls to the DST were to be made except
if a time tclock had already passed since the last call and if there were any new information
i.e. if Check_new_airplanes() or Check_distances() changed anything in the FP_list.

On the upper side, this strategy is less chaotic since it is not always calling the DST, allowing
for a decent time of exposure for the solutions while the drawback is the same as in the
previous strategy, aggravated by the fact that the more the time where no calls to the DST
are made, the higher the probability that the exposed solution is no longer valid.

• Let the ATCO decide when to call the DST, using a button created for that effect. While a
new solution is being sought the last valid solution is showed in the plug-in’s display area
and the created button is not available for the controller to press.

The advantages of this approach are: less chaotic than the first strategy since the DST does
not need to be constantly called in crowded scenarios; it allows for a better approximation of
the real conventional ATC, since in it controllers have to receive the aircraft positions, input it
in the system and only after shall they give the instruction to the airplane. With this strategy,
the controller has to manually call the DST after issuing an instruction to an aircraft, better
approaching the amount of workload needed at each waypoint in real oceanic ATC.

On the other side, the disadvantage is the same as the one in the strategies before: the last
solution showed while a new call to the DST is being made can be outdated.

Looking at the three strategies, the latter seemed more clean and appealing. Nevertheless, all
were implemented and tested and ultimately came the confirmation that the third solution was the
best suited for our purposes.

3.2.5.1 Final plug-in’s interface

Some alterations were made to the plug-in’s interface in order to accommodate the new require-
ments. Those alterations and the resulting interface are then discussed.
First, a button on top of the display area titled “Call DST” was created. It allows for new calls to
the DST and whenever there is new information – i.e. when conditions 1 or 2 are met – the button
turns red and the text is modified to “Call DST (REQUIRED)”, so as to notify the responsible
controller that a new call to the DST is advised – situation depicted in figure 3.8a.
The other modification is that while finding a new solution the last valid one is showed in different
color and background so as to allow the ATCO to recognize it as being old. Also, the “Call DST”
button becomes grayed out i.e. not available to use until the current finding returns a solution –

31
 (a) Detail of button “Call DST (REQUIRED)“ (b) Detail of showing the last valid solution
while making a new call to the DST

Figure 3.8: Details of the final plug-in’s interface version

figure 3.8b. While the button is grayed out it is still updated and thus it can be grayed out and
indicating that a new call to the DST is necessary after the conclusion of the current search.
The previously showed figures constitute the final version of the plug-in and thus the one pre-
sented to the ATCOs.

3.3 Additional window for Euroscope

Besides the previous plug-in interface, designed to be used only when ATCOs want DST’s help,
an additional window was made for controllers to use whether they are controlling a simulation
with or without the help of the DST.
Like discussed before, in oceanic control, pilots are responsible for reporting each aircraft’s
crossed waypoint to the ATCO in charge via voice communication. In Euroscope however, that
would be possible only by assigning each aircraft to a trained person entrusting them of being the
pilot and making the voice communications – such is done in virtual air traffic simulation. That
would of course require a big amount of human resources in relevant tragic scenarios for our
purposes i.e. where there can be 40, 50 or 60 aircraft at once in the scenario.
So as to replace the voice communications for something with the same valuable information
and thus help controllers by not compelling them to constantly check for each flight’s position
in search of waypoint reports, a window that constantly shows and updates the last reported
waypoints was created.
An example of one of these referred windows is depicted in figure 3.9. Analysing that figure,
from left to right, we observe that each report contains the following information: callsign of the
aircraft in question in the left, name of the reported waypoint followed by the hour of that report in
the middle and ground speed followed by the flight level at that reported waypoint in the right.
Each report stays available for 70 seconds, moment when it disappears from the list. The value

32
of 70 was devised to allow controllers enough time to notice the report and act on it if necessary.

Figure 3.9: Waypoint reports window

33
Chapter 4

Simulation and Results

The present chapter is concerned with the simulations conducted to test the developed plug-in
and the results that came from those tests.
First, in section 4.1 the defined parameters to establish the simulation environment are dis-
cussed and then in section 4.2 the trials’ proceedings are analysed.
Finally in section 4.3, the relevant test results from the surveys that were taken by the ATCOs
as well as some of the oral interviews’ responses are presented and discussed.

4.1 Simulation framework

4.1.1 Simulation parameters

To completely define the simulation framework used to test the DST integrated in Euroscope
via plug-in, the same assumptions made for the DST in subsection 2.1.3 are used, with two
exceptions:

• Aircraft models

As mentioned before, an effort to have a wider variety of functional aircraft models, instead
of just the A320 used in the DST’s simulations, was made. Thus, the available models were:
A319, A320, A321, A332, A333, A343, A346, B77W, B744, B752, B763.1

• Simulation duration

A time window of one and a half hours for the DST was used. This value is related to the
fact that the trials with the ATCOs, as discussed further, were defined to be of one hour in
each simulation. The fact that the simulation duration is 30 minutes longer than each trial
duration is a way of giving some leeway in case the trial is delayed for some minutes.

λN
Also, the value of 10 was used for the criteria weight ratio λD as: it is in the order of magnitude
recommended by the DST maker; it have been a value that responded well during the hours
testing the plug-in. Therefore, more emphasis on having fewer instructions was given at the
expense of having a somewhat bigger vertical deviation from the RFLs.
1 Models with first letter A like the A319 are Airbus while the ones with first letter B like B77W are Boeing.

35
4.1.2 Traffic generation
In order to generate the traffic scenarios that are loaded by Euroscope, two approaches were
followed: one that generates a random scenario based on a nominal flight plan pool and is to
be referred as Random Traffic Situation and another that replicates a real traffic situation that oc-
curred in a certain oceanic airspace at a given time, further referred to as Real Traffic Situation.
As to generate traffic scenarios as real as possible, both use real flight plans. The first by down-
loading the flight plan pool from the Data Repository Demand 2 (DDR2) of EUROCONTROL’s
extranet and the latter by using EUROCONTROL’s modeling tool Network Strategic Tool (NEST)
to download and export to readable content the numerous Aeronautical Information Regulation
and Control (AIRAC) available cycles2 .

4.1.2.1 Random traffic situation

In this traffic generation routine, a numerous number of traffic samples was downloaded from
DDR2. Those samples represent all the flights that took place between various airports-pairs
– e.g from Madrid-Barajas airport (ICAO code: LEMD) to John F. Kennedy airport (ICAO code:
KJFK), during the month of January 2014, where the choosing of airport-pairs was made so as to
pick the ones where most of the routes between them would intercept the oceanic airspace that
was being used. A total of 11 airport-pairs were considered and a nominal flight plan pool with 46
flights was constructed for the special case of the LPPO. Each nominal flight plan contains:

• ICAO airline designator

• ICAO codes for origin and destination airports

• Aircraft model

• True airspeed in knots (T ASnom )

• Cruise FL (CF Lnom )

• Waypoints of the route throughout the oceanic FIR (route)

• Flight’s frequency

The last parameter needs some explaining. So as to generate more authentic traffic scenario
files, it makes sense that a flight that happens regularly is present in more generated scenario
files that one that is less frequent. The flight’s frequency takes care of that and has then three
possible values depending on the number of flights in the downloaded sample:

• High (H): the number of flights in the sample is greater than or equal to 40;

• Medium (M): the number of flights in the sample is greater than or equal to 20 and smaller
than 40;

• Low (L): the number of flights in the sample is less than 20.
2 AIRAC cycles have duration of 28 days and are used to disseminate information concerning significant changes.

36
The occurrence probability for flights with H, M and L flight frequencies are expressed respectively
as pH ,pM and pL and the relation between these probabilities was set to be pH = 2pM = 3pL .
As input, the traffic generation routine receives the desired Number of Current Flights (NCF ) as
well as the desired Number of Future Flights (NFF). The NCF represents the number of aircraft
that are present when the simulation begins and these aircraft can either be flying inside the
oceanic FIR or outside it and planning to enter it at a given time during the simulation. On the
other hand, the NFF represent the aircraft that are going to appear later along the simulation.
So, while the NCF flights are placed at a random waypoint of their route by the traffic generation
routine depending solely on whether it is inside or outside the oceanic FIR, the NFF ones, as
in real life ATC, can only be placed in one of the waypoints of its route that is prior to entering
the FIR The reason for this is simple: aircraft cannot magically appear inside a FIR that is being
controlled, they need to come from somewhere.
After picking some flights from the nominal flight plan pool, the routine calculates the random-
ized components for each flight:

• Callsign: a valid callsign is given to each aircraft having in mind that there cannot be two
aircraft with the same callsign at a certain moment during the simulation. E.g. IBE352.

• Squawk code3 : a valid squawk code between 3000 and 4000 is attributed to each flight.
The squawk code, like the callsign, is unique for each aircraft.

• Cruise FL: the requested cruise altitude CFL is calculated by applying a certain offset F Lof f
to the nominal cruise altitude, CF Lnom . That offset is calculated with a normal (or Gaussian)
distribution (F Lof f ∼ N (0, σf2 l )) and is rounded to the nearest multiple of ten, being later
added or subtracted to the CF Lnom to obtain a new altitude CF L.

CF L = CF Lnom + F Lof f (4.1)

• True airspeed: true airspeed is also generated with the help of a Gaussian distribution,
with T ASnom as the expected value and given in the nominal flight plan, and σT AS as the
standard deviation.
T AS ∼ N (T AS nom, σT2 AS ) (4.2)

• Current waypoint: there are differences whether the flight is part of the NCF or the NFF

– NCF: for each flight it is randomly chosen one of two states. It can be inside the oceanic
FIR or outside the FIR and planned to enter it at a given time during the simulation. If
the flight is inside the oceanic FIR, the current waypoint (currentW P ) is calculated by
assuming a uniform probability distribution between the waypoint of the route where
the aircraft enters the FIR (route[entryW P ]) and the waypoint where the aircraft exits
the FIR (route[exitW P ]).

currentW P ∼ U (route[entryW P ], route[exitW P ]) (4.3)

3 Four digit numbers transmitted by the transponder in an aircraft to uniquely identity an aircraft, allowing for easy identi-
fication of aircraft on radar. Same as transponder code.

37
 If the flight is planned, the currentW P falls in the interval of the first waypoint of the
route (route[0]) and the last waypoint of the route before the entry waypoint that does
not belong to the oceanic FIR (route[entryW P − 1]).

currentW P ∼ U (route[0], route[entryW P − 1]) (4.4)

– NFF: for these flights, there is only one possible state because of what was previously
stated about the impossibility of the aircraft to appear in the middle of a FIR during
the simulation. Then, that state is planned and so the currentW P is calculated as
before between route[0] and route[entryW P − 1] having the same uniform probability
distribution as in equation (4.4).

• Delay minutes: this is just applicable to the NFF flights and it is also calculated assum-
ing a uniform probability distribution between 1 minute and the duration of the simulation
(duration) minus 70 minutes. The delay in minutes (delaymin ) falls then inside the interval
[1, duration − 70]. The reason for choosing 70 minutes as the quantity to subtract to the du-
ration is explained hereafter. As NFF aircraft are always placed one or two waypoints away
from the FIR border and assuming, based on an educated guess that the average aircraft
takes between 25 and 35 minutes to cross a segment between two waypoints, the value of
70 minutes was used to guarantee that the last aircraft to be placed in the simulation would
still be an active aircraft inside the oceanic FIR, enabling all the aircraft to be relevant for the
simulation.

• Other: although not important to the objectives of this thesis, there are other components
that are mandatory in any Euroscope scenario file and so they were calculated with the same
rigor as the ones above. They are: departure time from origin airport, predicted arrival time
to destination airport, time en route and time of available fuel.

As a result of this traffic generation routine, it was noticed that often multiple aircraft were placed
at the same waypoint. While that did not constitute a problem, as it often happens too in real life
ATC, there was a problem if they were simulated at the same waypoint and with the same FL.
So, in the NCF flights, one good and pretty straight-forward solution was to modify the routine to
always put the newly created aircraft in a new, random and different FL from the ones that are
already in that waypoint.
For the NFF flights however, is was more a question of what should be the ideal time separation
– in the form of delay minutes in the scenario file to insert the following aircraft – so that two
aircraft that start the simulation at the same waypoint and with the same FL can safely travel their
corresponding routes without conflicting with each other. With that in mind, some research on this
topic was made and the results are described below.
According to [23] , the longitudinal separation minima based on time in oceanic airspace for
turbojet aircraft flying along same/intersecting tracks at the same FL is 15 minutes, or 10 minutes if
navigation aids, such as radar coverage, permit frequent determination of position and speed. So,
like said before, as most of oceanic airspace is outside radar coverage, our nominal longitudinal
separation minima should be 15 minutes. However if the commonly required procedure know as

38
Mach Number Technique – described in detail in [24] – is to be applied, that nominal value is set
to be 10 minutes and can change according to two criteria:

1. If the preceding aircraft is flying at a true Mach number smaller than the following aircraft, the
nominal time should be increased by one minute for every increase of 0.01 in the differences
between the aircraft Mach numbers.

2. If the preceding aircraft maintains a true Mach number greater than the following aircraft,
the nominal value is to be decreased to a maximum of 5 minutes

Since in our case we have a pre-defined longitudinal distance minima of 50 NM to respect,

instead of the standard 10 minutes, our starting point is the amount of time the following aircraft
takes to travel 50 NM at its current speed, tnom . The change in the nominal value in turn, can only
be done by adding time tadd , according to condition 1, and not by reducing it as that would violate
the 50 NM minima. The total longitudinal separation time ttotal is then:

ttotal = tnom + tadd

where tadd is either 0 if condition 2 is verified or the difference between the following and the
preceding aircraft’s Mach numbers divided by 0.01.
The proper modifications in the traffic generation routine were then made in order to accommo-
date the respective solutions for both the N CF and the N F F flights.

4.1.2.2 Real traffic situation

The purpose of this routine is to replicate the real air traffic that occurred during a certain period
of time during a given day. It uses information coming from EUROCONTROL’s airspace modeling
tool NEST, which allows specific AIRACs to be downloaded and later transformed into readable
data such as Excel format in order to be properly treated. The information from the AIRACs is
very rich in both quantity and quality of material and has all the needed information to make a
scenario file suited to our purposes such as: complete set of waypoints of the aircraft route, FL
during the route, entry and exit time from the oceanic FIR, length and duration of the cross over
the FIR and thus, by a simple math operation, the aircraft velocity, etc.
Although having all the needed information, some calculations needed to be done concerning
the entry point of the aircraft in the simulation. Having just the entry and exit time of each aircraft,
the point where the aircraft are simulated had to be calculated with precision in order to avoid
aircraft to be simulated too close to each other and in order to successfully replicate the real air
traffic scenario.
First, with the Haversine formula, as referred in [25] and replicated in equations (4.5), that is
used to calculate the great-circle distance between two points, the length of each segment from
the aircraft’s route was calculated.

39
 ∆ϕ = ϕ2 − ϕ1
∆λ = λ2 − λ1
a= sin2 ( ∆ϕ
2 )+ cos ϕ1 · cos ϕ2 · sin2 ( ∆λ
2 )
(4.5)
√ p
c = 2 · atan2( a, (1 − a))
d=R·c

where ϕ is latitude, λ is longitude and R is earth’s radius. The intermediate result a is the square
of half of the straight-line distance between the two points and c is the great circle distance in
radians. The final value d is given in the same units as R.
Next, calculating the difference between the starting time of the simulation and the entry time
of each aircraft, the distance traveled inside the FIR (or distance left to travel until entering the
FIR if the aircraft is outside the FIR and planning to enter it) was determined using the previously
calculated velocities. With this, and using the results found with equations (4.5), the segment
where the aircraft should be simulated as well as the distance to the first waypoint of that segment,
dstart , were found.
After that, the initial bearing4 between the two waypoints of the present segment is calculated
using equation (4.6), that can be found in multiple websites, e.g. the one in footnote5 .

θ = atan2(sin ∆λ · cos ϕ2 , cos ϕ1 · sin ϕ2 − sin ϕ1 · cos ϕ2 · cos ∆λ) (4.6)

At last, using the start waypoint coordinates ϕ1 and λ1 , the initial bearing θ and the distance to
the start waypoint dstart , the destination point coordinates ϕ2 and λ2 were calculated using the
formulas below:

δ = dstart /R
ϕ2 = arcsin(sin ϕ1 · cos δ + cos ϕ1 · sin δ · cos θ) (4.7)
λ2 = λ1 + atan2(sin θ · sin δ · cos ϕ1 , cos δ − sin ϕ1 · sin ϕ2 )

where δ is the angular distance in radians.

This routine receives as input the starting time and duration of the simulation and outputs a
scenario file with every aircraft that is active throughout the duration.
In order to better determine which were the most interesting periods of time to analyze during
the ATCOs trials, graphics like the one in figure 4.1 where it can be seen that for the particular case
of the 9th of January 2014, the peak of traffic was from 11:00 to 14:00, were widely consulted.
These particular peak is due to the Europe to North and Central America traffic flow.

4.2 Trials with ATCOs

The objective of the trials with ATCOs was to ascertain which would be the potential benefits
and drawbacks of using the constructed plug-in in a simulated ATC environment – Euroscope in
4 In aerial terms, it means the actual compass direction of the forward course of the aircraft. Also referred to as the
forward azimuth.
5 http://www.movable-type.co.uk/scripts/latlong.html, last consulted in September 2014.

40
 Figure 4.1: Entry counts in the LPPO during 9th January 2014

ATCO
A B C D
I II I II
1st
DST_ON DST_ON DST_OFF DST_OFF
Trial
II I II I
2nd
DST_OFF DST_OFF DST_ON DST_ON
Table 4.1: Scheme plan of the experiments with four controllers

our case. It would serve as an intermediate step while evolving the DST into one integrated in the
real ATC world and used on the day-to-day of controllers.
Ideally the trials would be taken by several sets of four ATCOs, each set having the configuration
depicted on table 4.1. The conditions to take into account when attributing each experience
framework were:

• Scenario files: I and II;

• Conditions while controlling: with the help of DST (DST_ON), without the help of DST
(DST_OFF ).

The duration of each trial would be of four hours, which is half of the typical duration of a
controllers’ shift.
In order to have interesting and reliable data to analyze corresponding to two scenario files, 12
or 16 controllers (three or four sets of trials respectively) would be enough. The reliable factor
is related to the elimination as well as possible of the ambiguity aspect that is inherent to all
experiments. In this case, the ambiguities’ elimination can be pinpointed by understanding that
the scheme’s distribution of table 4.1 is not random. Instead, three conditions rule the distribution:

41
 • Each scenario file is attributed only once to each controller, assuring that ATCOs do not su-
pervise the same scenario file more than once, precluding a preconditioning in the results –
coming from previous insight – on the second time the scenario would have been controlled.

• The order in which the DST is used is inverse for the first and latter two ATCOs. This guar-
antees that a better result in the second trial cannot be attributed solely to the experience
that the controllers have gained from the first trial. I.e. if the first trials were all made with
DST_OFF/DST_ON, a possible better result in the second round of trials could prone one
to attribute that success to the bigger ATCO’s experience on handling Euroscope, thus ne-
glecting the fact that the DST had worked well or not – for having initial DST_OFF and
DST_ON respectively.

• Each scenario file is going to be controlled in every possible situation, i.e. in both the first
and second trials with both DST_ON and DST _OFF. That is why the defined number of
ATCOs for a set was four and not five, three or two. Thus, final results’ conclusions cannot
be attributed to scenario I being much easier or much harder than scenario II.

In the other hand, to turn the experiment into one with enough dimension to withdraw statistical
significance, the more human resources the better of course, but something along the lines of
testing 4 pairs of scenario files and hence 48 to 64 ATCOs would be sufficient.

4.2.1 Pilot trial

Since the necessary human resources to make this experiment into one with valid statistical
results were fairly big, and therefore outside the range of our capabilities to get, a pilot trial serving
as a proof of concept was conducted.
The trials were planned for two real ATCOs who made themselves available in their free time
for participating in the experiences but incompatibility in schedules coupled with the approach of
the thesis delivery time lead us to consider other options.
As an alternative to real ATCOs, virtual uncertified ATCOs were chosen. It is important to clar-
ify at this point that even though the virtual ATC world tries to replicate the real one as much as
possible, they are still two completely separate contexts and so there are still differences between
them. With that said, virtual ATCOs despite doing this as an hobby, can still be considered excel-
lent elements for the experiences and they have one advantage since they work on a daily basis
with Euroscope and hence are best fitted to assess the plug-in’s interface integration with the air
traffic simulation environment in question.
The two chosen virtual ATCOs are very active members in the Portuguese VATSIM community,
where ATCO A, between many functions, is supervisor and instructor to new members in various
Portuguese FIRs, being also certified to operate in LPPO and having 5 and a half years of expe-
rience in the virtual ATC world whereas ATCO B is the director of LPPO, has 7 years of virtual
controlling experience.
Thus, this trial was arranged with two virtual ATCOs during the 11th of October 2014. Both
trials occurred in the same day but separated by the time of day i.e. one in the morning and one
in the afternoon because it was a good idea to maintain myself (the plug-in developer) available

42
 ATCO
A B
I I
1st
DST_ON DST_OFF
Trial
II II
2nd
DST_OFF DST_ON
Table 4.2: Scheme plan of the experiments with two controllers

for any possible doubt or error during the simulations and that was achievable only by having the
tests happening at different times.
The duration of each trial was modified from four hours to one hour so as to accommodate the
fact that the ATCOs, doing the trials without being paid and on their free time, could not spend too
much time in the trials. That did not constitute a problem because a one hour trial is a very good
sample of what a four hour trial would be like and is enough to study the ATCOs response to the
developed plug-in.
Hence, the trials consisted of two tests, each with duration of one hour, with the help of two
ATCOs. They took place accordingly to the scheme depicted in table 4.2 in order to reduce the
ambiguity of the tests. Within this table, one can notice that two of the principles for ambiguity’s
reduction discussed before for the trials with sets of four ATCOs are still verified:

• Each scenario file is attributed only once to each ATCO.

• The order in which the DST is used is inverse for the first and second ATCOs.

However, and even though the ambiguity is almost eliminated by having used table 4.2, there is
still a third condition that cannot be taken into account with two ATCOs only: if the difficulty of one
scenario is much different than the other, the validity of the results is compromised.
For that reason, the chosen scenario files were similar in both the number of aircraft and in the
number of initial conflicts. Both were chosen from real traffic situations from the 17th of January
2014, during different periods of time. The first, I, taken from 12:00 to 13:00 had 50 aircraft present
in the simulation at the moment of the start and other nine planning to enter the simulated FIR at
some point during the simulation and the initial number of instructions to solve potential conflicts
was of seven. In the other hand, scenario II, taken within 14:00 and 15:00, had 56 aircraft at the
beginning and the same nine planning to enter the FIR. The number of initial instructions of this
second scenario file was nine.
Before the trials started, a 10 minute explanation about the DST objectives was made. Also,
the simulation framework previously discussed was presented to the controllers in order for them
to act according to the role intended for them. After that, and before the first trial, the ATCOs were
asked to use the presented tools for a couple of minutes to become accustomed to them.
The results from this pilot trial are discussed in the next section of this chapter.

43
4.3 Results
During the trials it was observed that each ATCO had a very different style of controlling.
Whereas ATCO A used all available tools in Euroscope while controlling the FIR, ATCO B had
a very conventional style, measuring for example the separation distances by eye. The result
of those different practices together with the fact that the number of airplanes to control was
significantly large, lead to imperfect controlling in the scenarios where the DST was not used.
I.e. the first ATCO failed to notice one of the conflicts and was late on noticing another, what
resulted in giving an instruction out of the standard period for instruction issuing – after waypoint
reports – while the second, managing the separation mentally only, discovered every conflict –
even though violating for a couple of times the horizontal separation minima – but gave relatively
more instructions in comparison.
In the session with the DST’s assistance, it was noticed that the ACTOs did not have much work
on their hands, taking advantage of their free time to check which aircraft conflict generated each
DST solution’s instruction. That was one of the improvement points an ATCO brought up saying
that “the plug-in could have a functionality that shows which was the conflict each instruction was
solving, by moving the mouse over each instruction. That way, the controller would be left with
an even easier task.”. This suggestion, although good and feasible has to be carefully considered
because of one aspect earlier discussed: the DST has to provide the exact right level of automa-
tion, not too much so as to hinder the controller’s ability to quickly reassure manual operation in
case of emergency. The suggestion is then left as a medium term work, when (and if) the level of
ATC automation becomes much higher.
All in all, objective results for the trials were ascertained by having the ATCOs present in the
trial answer the inquiry of annex A and by asking them, and recording with their consensus, other
development questions directly.

4.3.1 Inquiries

The filled inquiries are depicted in annex B. They show a very positive feedback from the
ATCOs, where they both strongly agree that the DST reduced their workload by allowing the
conficts’ prevention to occur more easily.
In the end, both wished to see the developed tool used in the virtual ATC system which consti-
tutes a very positive reaction and is aligned with this thesis’ objectives.

4.3.2 Qualitative feedback

The most relevant answers and the respective questions asked to obtain them are presented
below:

• Were you able to trust the DST’s solutions? Explain why.

ATCO A said “Yes, because the DST was able not only to predict a near-term conflict but also
one that was only going to take place many minutes from then, something that a controller
would not be capable of observing in that immediate” while controller B replied: “Yes, and

44
 the trust in the DST’s solutions came from finding that the conflicts were being solved with
the DST’s advisory instructions”.

• Did you think that the DST reduced the workload in comparison to the session without
the DST? Why?
ATCO A response was: “Absolutely! I think that it reduces approximately 70% of controller’s
workload and hence, airspace divided for two controllers could easily be supervised by one
ATCO only if being helped by this DST “.
ATCO B in its turn, said: “My workload was significantly diminished since I stayed completely
rested, when in the session without the DST I needed to constantly find possible conflicts
and solutions and then, the solutions that I have found turned out not to be the best ones”.

• Would you change anything about the DST to make it better ATC-wise?
Both ATCOs gave the same answer and said that it would be better if the information present
on “Waypoint Reports” window stayed there indefinitely instead of just for a certain amount
of time. That, coupled with the functionality of left-clicking over a report that is not needed
anymore and erasing it from the list by doing so, would in their opinion establish a better way
to inform the controllers about the aircraft’s whereabouts.
ATCO B also suggested that by right-clicking each report, instead of having to use the .find
Euroscope’s functionality to find each aircraft, a line showing the aircraft location should
prompt.

• Do you have any other observation?

ATCO A stated that “I was under the impression that the tool would be more relevant in
oceanic airspace only but I was left with the certain that it would also be of great help in
radar airspace areas that are sometimes full of traffic with intersecting routes and flying
from different FIRs”

In summary, the overall reaction to the constructed plug-in was excellent. Saying that the
workload was diminished by 70% and that you were left doing nothing in a scenario with 56
aircraft was even better than the projected ideal responses.
As for the suggestions from the question about possible DST improvements, they both seem
like a good step towards evolving the plug-in and are therefore left as future work.

45
Chapter 5

Conclusions

5.1 Conclusions

This thesis is included in the ATC automation research field and its importance came from the
increase in the air traffic that has been occurring in the past decades and the consequential ATCO
workload’s overload. It is the continuation of a thesis done in IST that resulted in a DST for the
specific case of the CD&R area from ATC automation. The DST had an interactive approach
allowing for solution searching with the help of the user input, fact that was very appealing to test
with ATCOs.
Thus, the objective of this work was to integrate the previously developed DST with an ATC
simulation environment via a plug-in in order to test it with ATCOs and ascertain the usefulness
of the tool. The chosen air traffic simulation environment was Euroscope because of its function-
alities, grand use in the virtual ATC control and of its similarities with the real ATC system and the
plug-in created was a DLL, capable of running in any computer with Euroscope installed.
The plug-in for Euroscope was constructed and some aspects of the DST were improved but
unfortunately, the interactive part of the DST was not working as expected and so this thesis
objectives had to be redefined and the plug-in had to be changed in accordance to those redefi-
nitions.
As for the testing phase, a proof of concept trial with two ATCOs and two air traffic scenario
files was conducted. Both qualities and flaws of the plug-in were found out during the inquiry
phase and the obtained results illustrate the benefits of controlling with the help of the DST, at
least in conventional oceanic control – which is the case where the simulations took place. The
controllers’ feedback was extremely positive and both said that the workload was diminished,
since they found possible conflicts more easily with the aid of the DST via plug-in. They were also
in favor of using the tool again in the ATC they practice nowadays.
The plug-in’s interface proved its robustness throughout the several hours of testing and during
the tests with the ATCOs. By robustness one is to understand not giving any critical error and
behaving as expected. The plug-in and DST connection however, was not always stable. Seldom,
some run time DST errors were given and as their resolution – even though tried – falls behind
the scope of this thesis, they are simply left as a reference for future work.
All in all, even with the DST working differently than expected, the ATCOs response level was
excellent and thus it was ascertained that the tool was an excellent help to ATC.

47
5.2 Future work
After the solving of the DST run time bugs is achieved, other suggestions for future work on how
to improve the developed plug-in were thought of and are herein presented:

• Test the interactive version of the DST. The interactive version is somewhat more interesting
to analyze than the one that this thesis had to focus on because it puts the controller more
in the loop of decision.

• Address a smaller longitudinal separation than 50 NM. The ultimate DST objective is not
only to diminish controllers’ workload but also to raise the air sectors capacity. By reducing
that minimum separation, the capacity increase is achieved because there is more “empty”
space for new airplanes to be placed at. This was tried in a non-official manner at the time
of the plug-in testing phase and the results were satisfactory. However, trying it with ATCOs
would be even more interesting: during the test with the help of the DST nothing would be
altered but they would need to get accustomed to the fact that the horizontal separation was
smaller when they were controlling without the help of the DST for comparison effects.

• Adapt this DST, from one used in oceanic control only into one that can be used even
where radar coverage is a reality. Doing this would involve changing the separation minima
and allowing for vertical instructions to stop being restricted to waypoint reports only. Also,
during the adaptation, the instructions could (and should) stop being vertical only and start
encompassing horizontal and speed changing maneuvers also, as it is done in conventional
radar ATC.

• Measure the level of workload in a quantitatively manner instead of how if was done here
i.e. qualitatively by asking the ATCOs to assess it. For example running a simple challenge
exercise simultaneously with the simulation that would pop-up from time to time and ask
the ATCO to introduce something in a time window of some seconds. The number of times
they fail to respond is directly related to their current workload. This exercise could be for
example one where the ATCO was asked to input the callsign of the last aircraft that crossed
a waypoint. This way, not only the workload but also their attention level to the traffic scenario
in question could be measured.

The lack of a bigger human resource pool prevented the putting into practice of some ideas, that
are therefore further presented for future work:

• Test with ATCOs under different criteria weight ratios λλN

D
. This was already done during
the DST testing phase but applying that in a situation where one can actually measure the
ATCOs workload would be much more interesting to ascertain the ideal weight ratio.

• So as to get statistical relevant data from the experiments with the ATCOs, the developed
plug-in can be tested with more controllers with different pairs of scenario files. A general
idea for the necessary numbers for both traffic scenario files and ATCO testers was given in
the previous chapter.

As a last suggestion for future work, the most difficult one is left. After everything from the
previous list is done, the final goal is to integrate the DST with the ATC system instead of with

48
Euroscope. The repetition of all the suggested tests as well as the perform of all the needed
procedures to validate the tool in the ATC world would be of course necessary.

49
Bibliography

[1] EUROCONTROL EUROCONTROL 20-year Forecast of Annual Number of IFR Flights

(2012-2035), June 2013.

[2] B. G. Hillburn, “Evaluating human interaction with advanced air traffic management automa-
tion,” RTO-MP-088 - The Role of Humans in Intelligent and Automated Systems, October
2003.

[3] C. D. Wickens, Engineering psychology and human performance . HarperCollins Publishers,

1992.

[4] F. Freitas, “Optimal air traffic control automation: Application to oceanic control,” Master’s
thesis, Instituto Superior Técnico, 2013.

[5] P. L. de Matos and D. Marsh, “Dss on trial,” OR Insight, vol. 13, no. 1, pp. 2–8, 2000.

[6] A. Kirlik, “Modeling strategic behavior in human-automation interaction: Why an aid can and
should go unused,” Human Factors, vol. 35, pp. 221–242, 1993.

[7] C. Meckiff and P. Gibbs, “Phare highly interactive problem solver,” EUROCONTROL, Novem-
ber 1994.

[8] A. Price and C. Meckiff, “Hips and its application to oceanic control,” Decision Support Tools
– Oceanic HIPS, 1997.

[9] J. Shepley, “Near-term terminal area automation for arrival coordination,” in Eighth
USA/Europe Air Traffic Management Research & Development Seminar, Napa, CA, 2009.

[10] D. McNally, H. Erzberger, R. Bach, and W. Chan, “A controller tool for transition airspace,” in
AIAA Guidance, Navigation and Control Conf, 1999.

[11] T. Prevot et al., “Trajectory-oriented time-based arrival operations: Results and recommen-
dations,” in ATM2003, FAA/Eurocontrol R&D Seminar, Budapest, Hungary, Citeseer, 2003.

[12] M. C. Picardi, “En route atm decision support tool computer-human interface requirements
development,” 2nd USA/EUROPE AIR TRAFFIC MANAGEMENT R&D SEMINAR, 1998.

[13] M. Brennan et al., “Evaluating en route congestion management through interactive simula-
tion,”

[14] R. Gingell, K. Corker, and E. Weber, “The feasability of measuring capacity in a real-time atm
simulation independent of subjective contcontrol worlkload measurement,” 2005.

51
[15] T. Prevot et al., “Automated air traffic control operations with weather and time-constraints,”
in Proceedings of the 9th FAA/Eurocontrol R&D Seminar, 2011.

[16] C. D. Wickens, “Imperfect and unreliable automation and its implications for attention alloca-
tion, information access and situation awareness,” 2000.

[17] L. Major, H. Johannsson, H. Davison, E. T. Hvannberg, and R. J. Hansman, “Key human-

centered transition issues for future oceanic air traffic control systems,” 2004.

[18] U. Metzger and R. Parasuraman, “Automation in future air traffic management: Effects of
decision aid reliability on controller performance and mental workload,” Human Factors: The
Journal of the Human Factors and Ergonomics Society, vol. 47, no. 1, pp. 35–49, 2005.

[19] J. Sanchez, C. J. Krumbholz, and M. O. Silva, “Controller-automation interaction in nextgen:

A new paradigm,” February 2010.

[20] J. Krozel et al., “System performance characteristics of centralized and decentralized air
traffic separation strategies,” 4th USA/Europe ATM R&D Seminar, 2001.

[21] ICAO, “Doc. 9574 an/934,” Manual on Implementation of a 300 m (1000 ft) Vertical Separation
Minimum Between FL 290 and FL410 Inclusive, Edition 2002.

[22] NAV, Implementation Plan for the Apllication of 50 NM Lateral Separation in Santa Maria
CTA, July 2013.

[23] ICAO, “Doc. 4444 atm/501,” Procedures for Air Navigation Services–Air Traffic Management
(PANS-ATM), pp. 69–101, Edition 2007.

[24] ICAO, “Nat doc. 007,” North Atlantic Operations and Airspace Manual, pp. 65–66, Edition
2013.

[25] R. W. Sinnott, Virtues of the Haversine, vol. 68. Sky and Telescope, 1984.

52
Appendix A

ATCOs Template Survey

53
Inquérito acerca da ferramenta de apoio
à decisão (DST)
Nome:

Cargo actual no ATC virtual:

Anos de experiência como controlador virtual:

Questões:
Discordo Discordo Sou Concordo Concordo
totalmente indiferente totalmente
Após a explicação
introdutória, a adaptação
ao sistema usado foi fácil.
A interface da DST é
intuitiva.
O tempo de espera por
soluções que foi verificado
é aceitável.
Confio nas soluções dadas
pela DST.
A DST possibilitou-me
prevenir possíveis conflitos
mais facilmente.
Senti que a minha carga de
trabalho foi reduzida com o
uso da DST.
Gostaria de ver esta DST
ser usada no controlo de
tráfego aéreo virtual.

54
Appendix B

ATCOs Answered Surveys

• ATCO A

55
 • ATCO B

56