optimal air traffic control automation: application to ... · optimal air traffic control...
TRANSCRIPT
Optimal Air Traffic Control automation: application tooceanic control
Francisco Manuel de Melo Sousa Jarnac de Freitas
Thesis to obtain the Master of Science Degree in
Aerospace Engineering
Examination Committee
Chairperson: Prof. Doutor Joao Manuel Lage de Miranda LemosSupervisor: Prof. Doutor Rodrigo Martins de Matos VenturaCo-supervisor: Prof. Doutor Miguel Jose Simoes BaraoMembers of the committee: Prof. Doutor Pedro da Graca Tavares Alvares Serrao
October 2013
Abstract
The rapid increase in air traffic verified in the last few decades is now leading to capacity overload
in specific airspace sectors, where the amount of traffic approaches air traffic controller workload
limits. A common approach to tackle this problem is that of developing automated tools to assist
controllers in detecting and resolving conflicts.
A decision support system for controllers supervising the cruise phase is presented. The tool re-
ceives traffic situation updates as well as flight plan information and suggests ATC instructions that
ensure conflict-free trajectories. It operates in real-time, recalculating when new information is avail-
able. The trajectory of every aircraft in the scenario is predicted, within a given time window, with
wind as the only uncertainty source, modeled through a probabilistic framework. A conflict detection
and resolution module uses these trajectories to calculate plans that ensure safety and minimize a
multi-criteria cost function. This task is performed by a branch-and-bound search algorithm that guar-
antees optimality. The multi-criteria problem is solved using an interactive approach, which calculates
a relevant portion of the Pareto front obeying decision-maker preferences.
The problem of oceanic airspace was analyzed as a case study. Simulations were conducted by
feeding the algorithm with randomized traffic scenarios with increasing levels of traffic density and
complexity. The algorithm proved its effectiveness in solving even intricate traffic scenarios and the
importance of solution optimality was made evident by the verified reduction in cost relative to greedy
solutions.
Keywords: ATC automation, Conflict detection and resolution, branch-and-bound, interactive
decision-making, oceanic control
i
Resumo
O aumento de trafego aereo das ultimas decadas conduziu a que ocorra actualmente uma so-
brecarga em determinados sectores de espaco aereo, em que a quantidade de trafego se aproxima
do limite da carga de trabalho de um controlador aereo. Uma abordagem a este problema consiste
em desenvolver ferramentas automatizadas que assistam os controladores nas tarefas de detecao e
resolucao de conflitos.
Um sistema de suporte a decisao para controladores que supervisionam fase de cruzeiro e ap-
resentado. A ferramenta recebe planos de voo e reports de posicao e sugere instrucoes ATC que
asseguram separacao. Opera em tempo real, recalculando quando recebe informacao actualizada.
A trajectoria de cada aeronave e estimada, dentro duma janela temporal. O vento e introduzido de
forma probabilıstica como a unica fonte de incerteza. Um modulo de detecao e resolucao de conflitos
usa as trajectorias obtidas para calcular planos que assegurem a separacao e que minimizem uma
funcao de custo multi-criterio. Esta tarefa e assegurada por um algoritmo branch-and-bound que
garante optimalidade. O problema multi-criterio e resolvido recorrendo a uma solucao interativa, em
que uma porcao do conjunto de solucoes de Pareto e obtido segundo as preferencias do decisor.
O controlo em espaco oceanico foi escolhido como caso de estudo. Foram conduzidas simulacoes,
introduzindo no algoritmo cenarios de trafego aleatorios com nıveis crescentes de densidade e com-
plexidade de trafego. O algoritmo provou a sua eficacia, mesmo para cenarios intrincados, e a
importancia da optimalidade das suas solucoes foi evidenciada pela reducao de custo verificada
comparativamente a solucoes greedy.
Palavras-chave: Controlo de trafego aereo, Detecao e resolucao de conflitos, branch-and-bound,
decisao interativa multi-criterio, espaco oceanico
ii
Acknowledgments
I would like to express my gratitude to my supervisors Prof.Rodrigo Ventura and Prof.Miguel Barao
for guiding me throughout the development of this thesis. I believe their advice and knowledge have
allowed me to complete this work owning a more scientific, rigorous and methodical mind than I owned
at the beginning. This gratitude may also be extended to all the professors who have taught me in
Instituto Superior Tecnico. Many have left a mark on me, and I am certain I leave the school with
much more than a degree.
Even in a time in which a nearly infinite amount of information is available to anyone owning a
computer with an internet connection, receiving expertise from people with many years of experience
is invaluable. I have been fortunate enough to have been received at NAV Portugal twice in 2012,
and thus I would like to deeply thank all the professionals who have taken some of their personal time
to offer me insight on Air Traffic Control that I most certainly would not have gotten any other way. I
am grateful to Carlos Santos, for the care and enthusiasm he put into receiving me at NAV and for
granting me with the opportunity to visit the control room and experience an operational environment;
to Rui Rodrigues, for his patience in providing me indispensable details on ATC procedures, especially
on oceanic control, from the privileged point of view of a controller; to Jesus Conde, for the insight
provided in the area of traffic simulation. More recently, air traffic controller Nelson Pimentel was
invited to be part of the examination committee for this thesis, and kindly accepted, reviewing this
document and assuming an important role in the subsequent discussion. All these professionals
have helped me expecting nothing in return, out of pure generosity and passion about their jobs. For
this I thank them.
On a personal note, I thank the people to whom I owe the most. My mother and my father, for the
unconditional love and for giving me all I have ever needed, and then more. My grandparents, for their
support and enthusiasm, and for being the persons more eager to watch me graduate and succeed.
I thank all of the above, and I can only hope I prove to be worthy of everything I have received.
iii
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Approach outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Thesis contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Trajectory Prediction 7
2.1 Module Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Spherical Coordinates model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Trajectory simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Uncertainty modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Conflict Detection and Resolution 24
3.1 Fundamentals and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Conflict Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Cost Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Combinatorial Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Interactive Multi-Criteria Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 Simulation and Results 64
4.1 Simulation framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Algorithm performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Optimality analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5 Conclusions 78
5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
i
List of Figures
1.1 Overall operation scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 DSS and ACC breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 DSS and ACC breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Trajectory Prediction block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Rotation parameters representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Aircraft force diagram for steady leveled flight . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Longitudinal and lateral force diagrams. Control inputs (T , γ and φ) are shown in red . 19
2.6 Horizontal plane representation and relevant variables . . . . . . . . . . . . . . . . . . . 21
2.7 Relation between true airspeed, ground speed and wind vectors . . . . . . . . . . . . . 23
3.1 Aircraft protected zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Conflict avoidance horizontal maneuver . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Flight IBE123 horizontal route inside Santa Maria FIR . . . . . . . . . . . . . . . . . . . 30
3.4 Flight IBE123 altitude profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Particle by particle stochastic conflict detection . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Deviation Integral illustration for flight IBE123 . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Altitude profile and flight phases for the cruise portion of flight TP007 . . . . . . . . . . . 38
3.8 Illustration of the effect of cost deviation D on the climb phase of flight TP007 . . . . . 39
3.9 Illustration of the effect of cost deviation D on the descent phase of flight TP007 . . . . 40
3.10 Symmetric trajectories around FPL for the descent phase of flight TP007 . . . . . . . . 41
3.11 Deviation cost D calculation depending on deviation sign and flight phase . . . . . . . . 41
3.12 Search algorithm high level overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.13 Expansion of successors n′ of node n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.14 Example of search tree with depth 3, with respective stack of nodes . . . . . . . . . . . 48
3.15 Example of successor expansion and node update . . . . . . . . . . . . . . . . . . . . . 51
3.16 Pareto dominance illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.17 Pareto optimal set calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.18 Solution in a non-convex region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1 Randomized flight allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Node generation and expansion as a function of NF . . . . . . . . . . . . . . . . . . . . 68
ii
4.3 Boxplot representation scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Node generation and expansion as a function of NF . . . . . . . . . . . . . . . . . . . . 70
4.5 Maximum memory usage as a function of NF . . . . . . . . . . . . . . . . . . . . . . . . 71
4.6 Additional running time as an effect of optimality . . . . . . . . . . . . . . . . . . . . . . 72
4.7 Optimality gain Gopt variation with NF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.8 Handpicked scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.9 Altitude profiles for greedy and optimal solutions, using λNλD
= 1.0 . . . . . . . . . . . . . 76
4.10 Altitude profiles for the optimal solution with λNλD
= 1.0 and λNλD
= 300.0 . . . . . . . . . . 77
iii
Abbreviations
CPL Current Flight Plan
ATC Air Traffic Control
ATCO Air Traffic Control Officer
ATM Air Traffic Management
FL Flight Level
BADA Base of Aircraft Data
ECEF Earth-Centered Earth-Fixed
NED North-East-Down
ROCD Rate of Climb or Descent
ETA Estimated Time of Arrival
RVSM Reduced Vertical Separation Minima
FIR Flight Information Region
MCDM Multi-Criteria Decision Making
DM Decision Maker
iv
List of Symbols
Latin Symbols
CD Drag coefficient
CL Lift coefficient
Cfcr Cruise fuel flow factor
g0 Gravitational acceleration
h Altitude
m Mass
S Wing area
SH Horizontal separation
SV Vertical separation
T Thrust
Ts Discretization time step
tgreedy Time to find greedy solution
trun Running time
tsim Simulation time window
v True airspeed
vGS Ground speed
Greek Symbols
δGC Cross track deviation from great circle path
η Thrust-specific fuel consumption
γ Flight path angle
v
λ Longitude
φ Bank angle
ψ Heading angle
ρ Local air density
θh Heading error
ϕ Latitude
vi
1Introduction
1.1 Background
Although having proved to be sound and to assure a high level of safety over the past decades, the
current Air Traffic Control (ATC) system is now facing an increasing problem, and one that will require
a change of paradigm in the next few years, if air travel grows as predicted: capacity overload. Given
that air traffic controllers (also referred to as Air Traffic Control Officer (ATCO)) are already working at
the top of their capacities, an increase in their workload would most likely be a threat to system safety.
A future ATC system can only safely handle the predicted growth in air traffic if solutions are found to
increase each controller’s performance, and the number of aircraft he can separate on a given sector.
Several approaches have been studied to tackle the problem, which differ on the level of change they
impose to the current system and on the system component they focus on.
One of the approaches being widely studied focuses on redesigning the existing airspace organi-
zation. European Union’s Single Sky program (SESAR) aims at creating airspace functional blocks
designed to simplify air traffic control, instead of using national borders, as is done today. Another
of SESAR’s long term goals is to implement an European Free Route system, allowing aircraft to fly
direct routes between desired fixes, rather than flying over the fixed routes on which the European
ATC system as relied for many years1.
Closely connected with the airspace redesign approach is the paradigm towards the decentraliza-
tion of ATC, based on passing some of the human controller’s tasks to the aircraft crews. Researchers
working on this paradigm envision a system in which aircraft self-organize themselves and perform
conflict detection and resolution autonomously, leaving controllers solely with a supervising responsi-
bility, and thus the possibility of controlling a larger number of flights safely. This would require that1http://www.eurocontrol.int/sesar/public/standard_page/overview.html
1
each aircraft had knowledge of state and intention of every other aircraft in its vicinity, and would
have to rely on accurate and verified airborne conflict detection and resolution systems, as the duty
of assuring separation could not be put on pilots’ shoulders.
A less drastic departure from the current system is the approach of developing computerized tools
to improve the performance of the current centralized system. In the present system, the tasks of
detecting and resolving potential conflicts are carried out by human controllers empirically, based
on analysis of surveillance data and operational experience. Developing tools that execute these
tasks (or some sub-tasks that compose them) is an effective way of lightening the burden on ATCOs.
Solutions inserted in this approach may present high variation in the automation level they implement.
They may range from simple tools, that detect short- and medium-term conflicts without suggesting
any solutions – already being widely used in Europe, e.g. Medium Term Conflict Detection (MTCD)[1]
and Short Term Conflict Alert (STCA)[2] – to total automation, in which an automatic tool detects
potential conflicts, calculates an optimal solution and issues the instructions to the aircraft by means
of some form of digital data format, performing every function of human controllers, and effectively
replacing them.
A study analyzing the various automation strategies that might be employed in a future Air Traffic
Management (ATM) system was conducted under an European project called RHEA (Role of the
Human in the Evolution of ATM systems) [3], in which advantages and drawbacks were presented for
the several automation levels. One of the suggested strategies, and a well-suited option for short-
term application, is the midway solution of developing tools that detect conflicts and calculate a set
of solutions, but present them merely as advisories, letting the human controller have the final word
on whether to accept the solutions or come up with its own. An emphasis is put on the concept of
cognitive tools, in which the developed algorithms are designed to follow a controller’s mental model,
rather than being purely mathematical. A cognitive tool is built to respond to a certain situation using
strategies close to the ones a controller would employ. Solutions following this concept increase
a controller’s trust in the suggested advisories, somehow mitigating one of the main drawbacks of
automatic conflict detection and resolution tools: due to the opacity of the algorithms, controllers do
not understand how a certain solution was achieved, and tend to distrust it. This drawback may be
minimized if the controller acknowledges the inner workings of the developed tool, even if only at a
high level.
The present work proposes a decision support tool inserted in the latter automation strategy.
1.2 Objectives
The objective of this thesis is to develop a decision support tool that analyses the traffic situation on
a given region, predicts the future trajectory of the aircraft being controlled, executes conflict detection
and resolution, calculates a plan and provides it as an advisory to the enroute air traffic controller in
charge of that region. The developed program must fulfil the following requirements:
• Run in a real-time framework, recalculating the advisories every time relevant information (e.g.
2
position reports from aircraft) is received.
• Calculate plan interactively, inserting the ATCO in the optimization loop.
• Calculate optimal solutions according to the defined cost function.
1.3 Approach outline
Prior to describing the operation of the developed program, it is useful to clarify how the tool is
integrated in the overall system. The framework in which the proposed tool is to operate is shown
schematically in figure 1.1.
In the figure, two blocks representing the two main entities involved in the ATM system model
developed in this thesis are identifiable: Area Control Center (ACC) – the air traffic control service
responsible for a given airspace – and Decision Support System (DSS) – the computerized system
that supports the operation of an ATCO.
The Area Control Center and the Decision Support Tool exchange information continuously. The
support tool receives as inputs (summarized as Flight Information) the flight plans of every flight
planned to fly inside the given airspace, updated surveillance data and restrictions received from pi-
lots, allowing it to have knowledge of the current state. The program uses this information to calculate
a safe and efficient set of instructions, which it then presents to the ATCO as an advisory.
The arrows linking the Area Control Center and the aircraft represent all the communication es-
tablished between the two parts, in both ways, for ATC reasons. This communication is usually made
through VHF radio signal, but it can also be established via HF (High Frequency), when the aircraft
is outside VHF range, or through CPDLC (Controller-Pilot Data Link Communication)2. It includes
the orders given and queries made by ATCO and the preferences or vetoes provided by the pilots in
response to a given order.
It is worth emphasizing that there is no direct connection between the support tool and the aircraft,
indicating clearly that the developed tool does not issue instructions directly, and that a final call on
which decision to take always belongs to the human controller.
Decision Support
SystemArea Control Center
Advisory
Flight Information
Figure 1.1: Overall operation scheme
A high-level breakdown of the Decision Support Tool and the Area Control Center blocks, as well
as the integration between them, is shown in figure 1.2.2http://www.eurocontrol.int/sites/default/files/content/documents/official-documents/brochures/
2013-cpdlc.pdf
3
Trajectory
Prediction (TP)
Conflict Detection &
Resolution (CDR)
Trajectories
CPL
Air Traffic Controller
(ATCO)
DecisionsPreferences
Decision Support System
Flight Information
System
Surveillance Data FPL
Information Display
Area Control Center
Figure 1.2: DSS and ACC breakdown
The Decision Support Tool is divided into two components: Trajectory Prediction and Conflict De-
tection & Resolution. These blocks are the central subject of chapters 2 and 3, respectively. The
Area Control Center consists of two blocks: Flight Information System – representing the systems re-
sponsible for storing FPL information, collecting surveillance data and displaying relevant information
to the controller – and Air Traffic Controller – representing the human controller in charge of a given
airspace sector.
The approach followed in this work can be summarized as follows. The support tool receives as
inputs the current situation of a set of aircraft (Surveillance Data) and their filed flight plans inside a
certain flight region (FPL), and calculates their long-term predicted trajectories (Trajectories) within
a certain time window, using a point-mass dynamics model and a simplified autopilot (a process
executed by the Trajectory Prediction module) . Inside the Conflict Detection & Resolution module,
a combinatorial search is carried out to analyze each plan within the state-space. Pairwise conflict
detection is executed for each individual plan (a CPL in the figure). Each plan is assigned a cost
using a Cost Function taking into account the deviation from the filed FPL and the total amount
of ATC instructions, allowing a branch-and-bound method to be implemented, pruning regions of the
solution search tree and reducing simulation time, while assuring optimality. A Monte Carlo simulation
is ran as a robustness check to test each calculated plan. A set of particles is created for each
aircraft, simulating possible trajectories. At the end of the simulation, the algorithm returns a global
plan, consisting of a set of instructions to be issued to each aircraft, and presents this plan to the
human controller (the Decisions process in figure 1.2). The controller may accept the plan right away,
or may require a new plan from the program, indicating which cost parameter must be minimized,
and possibly introducing some new restriction (indicated as Preferences in the same figure). The
tool recalculates a new plan obeying the added restrictions, and this plan is again presented to the
4
controller. This cycle continues until the controller accepts a proposed plan or no feasible plan is
found. The algorithm is run every time a position report is received from an aircraft, ensuring the
current advisory is based on the most updated information available.
As a case study, we chose to analyze the operation in Oceanic Airspace, where conventional ATC
is used due to the lack of radar coverage. Restrictions were created so that aircraft fly their filed
horizontal route at the requested airspeed, and trajectory changes are only allowed in the vertical
plane, with instructions being issued only at report fixes.
To implement the algorithm, the chosen language was Python, due to its high-level nature and
available libraries. The most extensively used libraries in this work include numpy, matplotlib and
pylab.
1.4 State of the art
Air Traffic Management has been a heavily researched field, especially since the early 1990’s,
and a large number of ATM related publications can be found in literature. An extensive review is not
attempted in this dissertation, but useful surveys were conducted by Eurocontrol [4] and Kuchar and
Yang [5].
Regarding the Free Route concept proposed by Eurocontrol, large scale real-time simulation re-
ports may be found in [6] and [7], the report on a study conducted to measure human performance
may be found in [8], and a cost-benefit analysis of the Free Route Airspace concept is found in [9].
Literature on decentralized techniques is extensively reviewed by Krozel and Peters in [10], and
the same authors cooperated on a study comparing the system performance of centralized and de-
centralized strategies [11]. Relevant contributions in this area include a paper by Dowek et al. [12],
proposing a CD&R algorithm for an host aircraft assuming no cooperation from an intruder aircraft, a
study by Harper et al. [13] that suggests a principled negotiation approach to the decentralized ATM
problem and the work presented by Masoud in [14] that proposes hybrid vector-harmonic potential
fields to plan the paths of multiple agents.
The approach of developing tools to aid air traffic controllers in the current centralized system has
been explored in several publications. The studies described in [15] and [16] use Genetic Algorithms
to find resolution maneuvers. Chiang et al. describe a Computational Geometry methodology to
calculate conflict-free routes in [17]. In [18] and [19], 3D-trajectories are allocated using A* and
Genetic Algorithms. Optimal Control techniques are used in [20] to perform conflict detection and
resolution.
1.5 Thesis contributions
This thesis contributes to the area of air traffic control automation through the use of decision
support tools. It presents a method to devise a tool that works interactively with air traffic controllers,
providing suggestions that assure conflict-free trajectories and obey controller preferences. The de-
veloped method allows the controller to fine tune the trade-off between ATCO workload minimization
5
and aircraft trajectories efficiency.
The proposed tool was implemented through a program written in Python, and was subsequently
subjected to extensive testing using randomized traffic scenarios with several levels of traffic density.
The program behaved well and proved its ability to calculate optimal solutions for most scenario
dimensions, and showcased its ability to reduce the cost between a greedy solution and an optimal
solution, validating its relevance for the research field it is inserted in.
The results of this work have been published as an extended abstract and accepted for the pro-
ceedings of RecPad 20133.
1.6 Thesis structure
The remainder of this thesis is split into four chapters, with the following organization:
• Chapter 2 describes the dynamical model used to predict a future aircraft trajectory. The equa-
tions implemented to simulate the dynamics and the autopilot system of an aircraft are pre-
sented. The introduction of quaternion algebra to calculate great circle trajectories is justified
and the position update routine is described in detail. The way in which uncertainty is modeled
is laid out.
• The Conflict Detection and Resolution algorithm is presented in Chapter 3. The Conflict De-
tection routines are explained, for both the deterministic and the probabilistic cases. The Cost
Function allowing the hierarchization of solutions and the use of a branch-and-bound method
is described. The combinatorial optimization algorithm responsible for exploring the plan state-
space is explained in detail. The choice of an interactive decision making scheme is justified
and the way in which the algorithm receives information from the human decision maker and
uses it to search for an optimal solution is laid out.
• Chapter 4 presents the simulations carried out to test the developed algorithm, and the most
relevant results.
• The dissertation main conclusions are presented in Chapter 5, which also contains suggested
directions of future work related with this thesis.
3The 19th edition of the Portuguese Conference on Pattern Recognition, to be held in November, in Lisbon.
6
2Trajectory Prediction
In this chapter, the algorithm used to predict an aircraft future trajectory is presented. A high-
level overview of the Trajectory Prediction block is presented in section 2.1, and its components are
described. The spherical coordinates model is presented in section 2.2, and the necessary quaternion
algebra concepts are explained. The equations implementing the dynamics and autopilot of an aircraft
are the subject of section 2.3. The chapter is concluded in section 2.4, with the description of the way
in which uncertainty is modeled and introduced into the trajectory prediction algorithm.
2.1 Module Overview
The subject of this chapter, the Trajectory Prediction module, is integrated in the Decision Support
System tool as shown in figure 2.1. Its function is to calculate a prediction of the aircraft future
trajectories, that will then be used by the Conflict Detection & Resolution module to detect and resolve
potential conflicts.
2.1.1 Input/Output analysis
As figure 2.1 shows, this module receives input from three different sources:
• FPL: a structure containing the flight plan information for each flight in the present scenario. An
FPL element, corresponding to a single flight, is composed of the following fields: Callsign (a
string uniquely identifying the flight), Departure (ICAO code of the departure airport), Destination
(ICAO code of the destination airport), Model (the aircraft model), Airspeed (the requested
cruise airspeed, either in knots or in mach number), Route (the route to be followed by the
aircraft, as a sequence of fixes), Flight Profile (the requested Flight Level (FL) for each route
segment) and ETE (the Estimated Time of Entrance, corresponding to the estimated time of
7
Trajectory
Prediction (TP)
Conflict Detection &
Resolution (CDR)
Trajectories
CPL
Air Traffic Controller
(ATCO)
DecisionsPreferences
Decision Support System
Flight Information
System
Surveillance Data FPL
Information Display
Area Control Center
Figure 2.1: DSS and ACC breakdown
arrival at the first route waypoint). FPL data may be defined by the user, to allow the testing of
custom scenarios, but is immutable throughout a program run.
• Surveillance Data: the information enabling the module to create a traffic ’picture’ at the time
the simulation starts (the real time at which the controller is operating). This information may
come from two different sources: 1) transponder data received by a secondary radar or 2) voice
reports made by pilots. The surveillance data provides the initial conditions to be used in the
trajectory prediction routine.
• CPL: in ATC, a flight Current Flight Plan (CPL) corresponds to the flight’s FPL plus the changes
(if any) cleared by controllers, usually for separation, airspace restriction or weather reasons.
The controller may change each flight’s cleared airspeed, flight level or horizontal route. Each
element of the CPL structure, corresponding to a single flight CPL, contains the current plan
being simulated for that aircraft. This structure is frequently changed by the program, and may
also be acted upon by the controller.
Additionally, the Trajectory Prediction module uses built-in information from a function called BADA:
at the start of the program, a list of parameters is loaded from BADA 3.101 files, for each aircraft model
present in the FPL structure. These are model-specific parameters, necessary to the simulation of
each aircraft’s trajectory, and include aerodynamic coefficients, wing dimensions, service ceiling, stall
speeds for different aircraft configurations and fuel consumption coefficients. These parameters are
static, cannnot be changed by the user and never change throughout a program run.
The module has a single output, labeled Trajectories, which contains the predicted trajectory
(and other relevant flight data) of every flight (or a selected set of flights) in the current scenario,
within a certain time window. Flight data for a single flight contains such information as the flight’s
position, speed, control parameters, fuel consumption and flight phase. This data is fed to the Conflict
Detection & Resolution module, which will use the computed trajectories to detect potential conflicts.1Base of Aircraft Data (BADA) is an Aircraft Performance Model (APM) developed and maintained by EUROCONTROL
8
2.1.2 Module components
The Trajectory Prediction module is depicted in figure 2.2. An inspection of the figure indicates
that the module consists of two components:
• Dynamics: the dynamical model, where the motion equations are implemented and the trajec-
tories are generated.
• Autopilot: the autopilot system, responsible for calculating the control input values that will
guide the aircraft along their requested routes.
Dynamics
Autopilot
StateControl
FPL
BADA
CPL
Trajectories
Trajectory Prediction
Surveillance Data
Conflict Detection &
Resolution
Figure 2.2: Trajectory Prediction block diagram
These two blocks form a control feedback loop, in which the Dynamics module acts as the con-
trolled system and the Autopilot functions as the controller (according to control theory nomenclature,
not to be confused with the human air traffic controller often referred throughout this dissertation).
2.2 Spherical Coordinates model
2.2.1 Motivation
Since this work is concerned with the cruise phase of an aircraft flight, long length trajectories
must be considered and the effect of the curvature of the Earth cannot be neglected. Furthermore,
it is assumed that the path flown by an aircraft between fixes is a great circle (with variable bearing
relative to true north) rather than a rhumb line (a constant bearing path). These assumptions deter
the choice of the dynamical models commonly used to simulate aircraft trajectories, which represent
position on local Cartesian frames and update an aircraft position using kinematic motion equations
deduced from Newton’s second law.
An alternative way to represent and update an aircraft position while in cruise phase may be
formulated by observing that, when an aircraft is flying over a great circle, its motion across the
surface of the Earth corresponds to a rotation around some axis containing the center of the Earth.
This property of great circle navigation is utilized in this work, by calculating successive positions of
an aircraft along its route using rotations in 3D space. An aircraft position is then represented in the
conventional geographic coordinate system by spherical coordinates latitude (ϕ) and longitude (λ),
9
and the rotation performing the position update is calculated as a function of the local speed vector of
the aircraft.
Although the traditional approach to perform the calculation of rotations in three-dimensional space
is to use rotation matrices, the choice was to use quaternions in this work. This option yields simpler
notation and lower computational effort, since a rotation using quaternion requires less multiplica-
tions than the same operation using matrices. In his book on the subject [21], Kuipers exhaustively
examines the use of quaternions as rotation operators, comparing the behavior and suitability of
quaternion algebra and matrix algebra for several specific applications, citing great circle navigation
as a field where quaternions excel and prove their worthiness.
2.2.2 Quaternion algebra
Quaternions were first used by William Hamilton in the nineteenth century, presenting them as
an extension of the concept of imaginary number. A quaternion – denoted q – may be considered a
hyper-complex number of rank 4 and may then be represented as a 4-tuple of real numbers:
q = (q1, q2, q3, q4) (2.1)
or, alternatively, as a column matrix:
q = [q1 q2 q3 q4]> (2.2)
Different conventions are used for the representation of quaternions. This work follows the con-
vention used by Trawny and Roumeliotis in [22], which writes a quaternion as:
q = q1i + q2j + q3k + q4 (2.3)
where i,j and k are imaginary numbers satisfying the following conditions:
i2 = −1
j2 = −1
k2 = −1
−ij = ji = k
−jk = kj = i
−ki = ik = j
(2.4)
In this convention, q = q1i + q2j + q3k is the vector part of the quaternion and q4 is its scalar part. An
alternative way to write a quaternion, emphasizing its two distinct parts, is:
q = q + q4 (2.5)
A quaternion with scalar part equal to zero (q4 = 0) is called a pure quaternion.
An important operation for the implementation of 3D rotations using quaternions is that of quater-
nion multiplication (represented by the symbol ⊗). The product of two quaternions q = (q1, q2, q3, q4)
and p = (p1, p2, p3, p4) is also a quaternion, here denoted as r = (r1, r2, r3, r4). Taking into account
the relations described in equation 2.4, r is calculated as follows:
10
r = q ⊗ p = (q1i + q2j + q3k + q4)(p1i + p2j + p3k + p4)
= q4p4 − q1p1 − q2p2 − q3p3 + (q4p1 + q1p4 − q2p3 + q3p2)i
+ (q4p2 + q2p4 − q3p1 + q1p3)j + (q4p3 + q3p4 − q1p2 + q2p1)k
(2.6)
and thus the components of quaternion r may be calculated as:
r1 = q4p1 + q1p4 − q2p3 + q3p2
r2 = q4p2 + q2p4 − q3p1 + q1p3
r3 = q4p3 + q3p4 − q1p2 + q2p1
r4 = q4p4 − q1p1 − q2p2 − q3p3
(2.7)
The quaternion product may also be written in matrix form:
r = q ⊗ p =
q4p1 + q1p4 − q2p3 + q3p2q4p2 + q2p4 − q3p1 + q1p3q4p3 + q3p4 − q1p2 + q2p1q4p4 − q1p1 − q2p2 − q3p3
=
q4 q3 −q2 q1−q3 q4 q1 q2q2 −q1 q4 q3−q1 −q2 −q3 q4
p1p2p3p4
(2.8)
It should be noted that the quaternion multiplication operator is non-commutative. From this point on,
the symbol ⊗ is dropped, and a product between quaternions q and p is represented simply by qp.
As with conventional complex numbers of rank 2, a complex conjugate may be defined for a
quaternion. The complex conjugate of quaternion q = [q1 q2 q3 q4]> is denoted q∗ and is defined as:
q∗ = −q + q4 = −q1i− q2j− q3k + q4 = [−q1 − q2 − q3 q4]> (2.9)
The norm of a quaternion q is denoted ||q|| and is calculated using the formula:
||q|| =√q21 + q22 + q23 + q24 (2.10)
A quaternion may represent a rotation in R3, provided it satisfies the conditions:
q =
ux sin( θ2 )uy sin( θ2 )uz sin( θ2 )cos( θ2 )
=
[u sin( θ2 )cos( θ2 )
](2.11)
where u = (ux, uy, uz) is a unit vector.
In these conditions, q is a unit quaternion (||q|| = 1) and it is called a quaternion of rotation. The
direction of u indicates the axis of rotation and θ denotes the angle of rotation.
If a is a vector in three-dimensional space, represented in some cartesian frame by the coordinates
(ax, ay, az), a rotation of angle α about an axis defined by some vector k = (kx, ky, kz) transforms a
into a rotated vector a′ through the following expression:
a′ = qr∗ ⊗ a⊗ qr (2.12)
where
qr =
kx||k|| sin(α2 )ky||k|| sin(α2 )kz||k|| sin(α2 )
cos(α2 )
=
[kn sin(α2 )
cos(α2 )
](2.13)
11
is a rotation quaternion with kn = ( kx||k|| ,
ky||k|| ,
kz||k|| ) a normalization of vector k. Also in equation 2.12,
if a is a quaternion with a vector part equal to the original R3 vector a, and scalar part equal to zero,
i.e. a pure quaternion defined as:
a =
axayaz0
=
[a0
](2.14)
then a′ will also be a pure quaternion, defined as:
a′ =
a′xa′ya′z0
=
[a′
0
](2.15)
where (a′x, a′y, a′z) are the coordinates of a′, the rotated vector, in the original cartesian frame.
2.2.3 Aircraft position representation
The model implemented in this work represents a position over the Earth surface by a rotation
quaternion. This is achieved by first defining a reference position over the globe, represented by a
reference R3 unit vector. The chosen R3 unit vector is denoted ri, with ||ri|| = RE (where RE denotes
the Earth radius), with its origin at the center of the Earth, and pointing to the North Pole, i.e. ri may
be expressed in an Earth-Centered Earth-Fixed (ECEF) coordinate system as ri = (0, 0, RE). Any
point A over the Earth surface may then be represented by the rotation needed to transform vector ri
so that it points to A.
At the start of the simulation, the algorithm calculates a quaternion corresponding to the initial
position of each aircraft, denoted q0. An initial position A over the Earth surface, with geographic
coordinates ϕ0 and λ0, may be represented by a rotation of unit vector ri into another vector r0 that
points to position A, as shown in figure 2.3(a) (where the represented frame is ECEF).
This rotation is fully defined by an axis of rotation k – which lies on the equatorial plane – and
by a rotation angle θ . Two planes are considered in order to obtain the rotation parameters: the
equatorial plane (shown in figure 2.3(b)), and a vertical plane (perpendicular to the equatorial plane)
which contains vector ri and point A (shown in figure 2.3(c)).
A quick inspection of figure 2.3(b) reveals vector k to point to a longitude of λ0 + π2 and thus its
coordinates are (RE cos (λ0 + π2 ), RE sin (λ0 + π
2 ), 0), whereas 2.3(c) shows that the rotation angle
depends solely on point A’s latitude: θ = π2 − ϕ0.
As described in the previous subsection, this rotation may then be represented as a quaternion
q0:
q0 =
ux sin θ
2
uy sin θ2
0cos θ2
(2.16)
where u = (ux, uy, 0) = k||k|| is a unit axis of rotation and θ is the rotation angle. This quaternion
rotates unit vector ri into position vector r0 using the expression:
r0 = (q0)ri(q∗0) (2.17)
12
x y
z
λ0
Ar0
ϕ0
ri
(a) Point A and vectors r0 and ri
x
y
k
A
λ0
λ0 + π2
(b) Vector k on equatorial plane
z
A
r0 ϕ0
θ
(c) Rotation angle θ on vertical plane
Figure 2.3: Rotation parameters representation
13
From this point onwards, quaternions that represent the position of an aircraft are referred to as
a position quaternions, and are denoted as qp. Quaternion q0 is the first position quaternion of the
simulation, and is used to recursively calculate the quaternions for subsequent positions, as explained
in the next subsection.
2.2.4 Position update
As mentioned in 2.2.1, the position of an aircraft at some instant is calculated in this model by
applying a rotation to the previous position. Assuming the system is discretized, with some time step
Ts and discrete index k, i.e. t = kTs, the position quaternion representing the position of some aircraft
at iteration k may be calculated recursively using the following formula:
qp[k] = qrot[k]qp[k − 1] (2.18)
where qrot[k] is a rotation quaternion. This quaternion applies the appropriate rotation to the previous
position quaternion, and depends on the aircraft speed vector.
To provide further insight, and before describing the calculation of rotation quaternion qrot[k], equa-
tion 2.18 may be expanded by successively replacing the position quaternion at the right side of the
equation by the corresponding expression, which yields:
qp[k] = qrot[k]qrot[k − 1]qp[k − 2] = qrot[k]qrot[k − 1]qrot[k − 2](. . . )q0 (2.19)
The above form of the equation emphasizes the notion that the position quaternion at some iter-
ation k is the result of successively multiplying each calculated rotation quaternion on the left of the
previously obtained position quaternion. The position quaternion qp[k] is then obtained by succes-
sively rotating the initial position quaternion q0 at each iteration.
The calculation of a rotation quaternion qrot[k] is carried out as follows. At some iteration k of the
algorithm, the aircraft is at geographical position (ϕ[k], λ[k]), equivalent to some position quaternion
qP [k], flying between an initial waypoint located at (ϕi, λi) and a final waypoint located at (ϕf , λf ). It
flies at altitude h and true airspeed v.
By taking into account the current position of the aircraft and the desired path between the two
waypoints, the aircraft’s autopilot calculates the appropriate heading ψ (the control scheme responsi-
ble for this calculation is described in section 2.3) and ensures it is followed by the aircraft, using the
available control inputs.
Assuming leveled flight, and thus zero vertical speed, it is possible to obtain the aircraft’s speed
vector expressed in a North-East-Down (NED) local frame, denoted vNED, by decomposing ground
speed vector vGS using heading angle ψ:
vNED = (vGS cosψ, vGS sinψ, 0) (2.20)
In the absence of wind, ground speed vector vGS and true airspeed vector v are the same. They
may differ (both in direction and in module) if wind is introduced. The introduction of wind will be
discussed later, and in this discussion, it will be assumed that no wind is present.
14
vECEF, the aicraft’s speed vector expressed in the ECEF frame, may then be calculated through
successive rotations of the vNED vector about the Latitude and Longitude angles:
vECEF = (qϕqλ)vNED(q∗ϕq∗λ) (2.21)
where qλ and qϕ are the appropriate rotation quaternions to rotate the NED frame into the ECEF
frame. These rotation quaternions are defined as:
qλ =
00
sin λ2
cos λ2
(2.22)
qϕ =
0
sin (−ϕ2 −π2 )
0cos (−ϕ2 −
π2 )
(2.23)
The assumption of leveled flight (and thus zero vertical speed) means that vECEF is a tangential
speed in an Earth spherical coordinates system, and the aircraft’s angular velocity may be obtained
using vECEF and r, the aircraft’s position vector in ECEF coordinates, rearranging the tangential
speed expression:
vECEF = ω × r ⇒ ω =r× vECEF
||r||2
In [22], Trawny presents a zeroth order quaternion integrator, which calculates a quaternion rep-
resenting a rotation of ω over a ∆t time interval (in our case, ∆t = Ts). The result is used here, and
a rotation quaternion at iteration k is finally calculated as:
qrot[k] =
ωx||ω|| sin
α2
ωy||ω|| sin
α2
ωz||ω|| sin
α2
cos α2
(2.24)
where α = ||ω||Ts is the angle of rotation about ω.
Having obtained the rotation quaternion needed to update the aircraft position, the algorithm cal-
culates position quaternion qp[k + 1], which specifies a unique aircraft position. This quaternion may
be transformed into geographical coordinates by first calculating the corresponding position vector r
using equation 2.17 and then obtaining the geographical coordinates from vector r through:
ϕ[k + 1] = arcsinrz||r||
(2.25)
λ[k + 1] = arctan2(ry, rx) (2.26)
where arctan2 is a variant of the arctangent function that correctly chooses the quadrant in which the
angle is situated, avoiding the ambiguity between angles separated by π radians.
2.3 Trajectory simulation
2.3.1 Dynamical model
The equation system used to simulate an aircraft trajectory was based on the one presented by
Glover and Lygeros in [23]. Having at its disposal the current state of an aircraft (from surveillance
15
Symbol Value Unit Descriptiong0 9.80665 ms−2 Gravitational accelerationT0 288.15 K Standard atmospheric temperature at MSLp0 101325 Pa Standard atmospheric pressure at MSLρ0 1.225 kgm−3 Standard atmospheric density at MSLβT 0.0065 Km−1 ISA temperature gradient with altitudeκ 1.4 - Adiabatic index of airR 287.05287 m2K−1s−2 Real gas constant for airhtp 11000 m Tropopause altitude
Table 2.1: Atmosphere model parameters
data) and an aircraft-specific model (loaded from BADA), the trajectory of that aircraft is calculated
using a point-mass model. A six-state control system is implemented, with the following state vector:
x =
x1x2x3x4x5
=
qphvψm
(2.27)
where qp denotes a position quaternion, as described in section 2.2; h represents altitude; v is the
true airspeed; ψ is the aircraft heading (relative to the air flow); and m denotes the aircraft mass.
The system is controlled by a three-input control vector u, where the three control variables are
engine thrust T , bank angle φ and flight path angle γ. These control inputs constitute the autopilot
system, and the equations defining them are presented in subsection 2.3.2.
The model is defined by the following differential equation system:
x =
qrot
v sin(γ)
− 12CDSρv
2
m − g0 sin(γ) + Tm
12CLSρvm sin(φ)−CfcrηT
(2.28)
where ρ is the local air density, CL is the lift coefficient of the aircraft, CD its drag coefficient, S
its wing area, η the thrust-specific fuel consumption and Cfcr a cruise fuel flow factor. Details on the
calculation of these variables are given below.
2.3.1.A Atmosphere model
In order to calculate the local air density ρ as a function of altitude, an atmosphere model was
implemented, following the one described in BADA’s User Manual [24]. The necessary parameters
for the implementation of the atmosphere model are summarized in table 2.1.
Since the program is built to simulate the trajectories of aircraft in their cruise phase, and given that
some aicraft models fly routinely at flight levels up to 41000 ft, the model must account for the effect
of the tropopause (defined at BADA as being at an altitude of htp = 11000m, around 36000ft), and
different equations must be used to calculate temperature and pressure above and below it. Hence,
a trop subindex indicates the formula is valid for altitudes inside the troposphere (h ≤ htp), whereas a
stra subindex indicates the formula is valid for altitudes inside the stratosphere (h > htp).
16
• Temperature (T)
Temperature below the tropopause decreases as altitude h increases, and may be calculated
using the expression:
Ttrop = T0 − βTh (2.29)
where h should be expressed in meters. In particular, temperature reaches a value Ttp at the
tropopause (h = htp), calculated as:
Ttp = T0 − βThtp (2.30)
Above the tropopause, temparature hits a plateau and remains constant throughout the strato-
sphere. Therefore, temperature in the stratosphere equals the temperature at the tropopause:
Tstra = Ttp (2.31)
• Pressure (p)
Air pressure below the tropopause is a function of the local temperature Ttrop, and may be
calculated as:
ptrop = p0(TtropT0
)g0βTR (2.32)
In particular, the air pressure at the tropopause (h = htp) reaches a value ptp:
ptp = p0(TtpT0
)g0βTR (2.33)
At an altitude h > htp, above the tropopause, air pressure is calculated using the formula:
pstra = ptp exp [− g0RTtp
(h− htp)] (2.34)
• Density (ρ)
Finally, air density may be calculated using the formula derived from the perfect gas law:
ρ =p
RT(2.35)
where p and T are the appropriate values for pressure and temperature, calculated depending
on the altitude being below or above the tropopause.
2.3.1.B Aerodynamic coefficients
The calculation of lift (CL) and drag (CD) coefficients assumes steady level flight conditions, as
shown in the aircraft force diagram in figure 2.4, where the four intervening forces are lift (L), weight
(W), drag (D) and thrust (T). These conditions yield:
L = W (2.36)
T = D (2.37)
17
• Lift coefficient (CL)
Given W = mg and L = 12CLρv
2S, rearranging equation 2.36 leads to the following expression,
that allows the lift coefficient calculation:
CL =2mg0ρv2S
(2.38)
where m is the aircraft mass and v is its true airspeed.
• Drag coefficient (CD)
Assuming nominal cruise conditions, the drag coefficient CD may be calculated as a function of
CL:
CD = CD0CR + CD2CRC2L (2.39)
where the first term (CD0CR ) represents the aircraft profile drag coefficient and the second term
(CD2CRC2L) is the induced drag coefficient. The coefficients CD0CR and CD2CR vary from model
to model, and depend on several aerodynamic parameters related with the design of the aircraft
wings, fuselage and tail.
2.3.1.C Fuel consumption
The thrust specific fuel consumption parameter η is calculated using the formula:
η = Cf1(1 +v
Cf2) (2.40)
where Cf1 and Cf2 are model-specific BADA parameters.
All the parameters used in the formulas above that depend on the aircraft model (Cf1, Cf2, Cfcr,
CD0CR , CD2CR and S) are read from BADA text files.
L
D
W
T
Figure 2.4: Aircraft force diagram for steady leveled flight
18
L
γ
D
W
T
(a) Longitudinal control
L
W
φ
(b) Lateral control
Figure 2.5: Longitudinal and lateral force diagrams. Control inputs (T , γ and φ) are shown in red
2.3.2 Autopilot
As mentioned in the previous section, the implemented trajectory prediction model assumes con-
trol of an aircraft is carried out by a three-input control vector:
u =
u1u2u3
=
Tφγ
(2.41)
where T is the thrust produced by the aircraft engines (in Newton), φ is the aircraft bank angle and γ
its flight path angle (both angles in radian). The three control components are represented in figure
2.5.
In order to control the aircraft and assure that it follows the desired reference values for true
airspeed, heading, vertical speed and altitude, the implemented control loop actuates by calculating
the error between the reference value for a variable and the current measured value for that variable,
adjusting the appropriate control input to bring that error to zero. The overall control system may be
separated into Longitudinal and Lateral control.
2.3.2.A Longitudinal control
Longitudinal control is concerned with the dynamics of an aircraft in the vertical plane. In the
present work, controlling the aircraft longitudinally consists of maintaining the true airspeed v and
altitude h requested for the cruise phase in its flight plan, and simultaneously controlling true airspeed
v and rate of climb h while performing a climb or descent.
The equations for true airspeed v and altitude h may be found in equation system (2.28), and are
19
reproduced here:
h = v sin(u3) (2.42)
v = −CDSρ2
v2
m− g0 sin(u3) +
1
mu1 (2.43)
Inspection of equations (2.42) and (2.43) indicates that the thrust (u1) and flight path angle (u3)
control inputs have an effect on both h and v. The choice was to control true airspeed v using engine
thrust u1 and to use the flight path angle u3 to control h when in cruise and h when climbing or
descending.
To perform control over true airspeed v, a proportional-integral controller (PI) was implemented,
with engine thrust u1 as the control input. Assuming the controller aims at maintaining a true airspeed
vref (defined in the flight plan), the control law for u1 is:
u1(t) = kp1ev(t)− ki1∫ t
0
ev(τ)dτ (2.44)
where
ev(t) = vref − v(t) (2.45)
is the instantaneous error, at time t, between FPL true airspeed vref and current true airspeed v. kp1
is a proportional gain, ki1 is an integral gain and∫ t0ev(τ)dτ is the accumulated true airspeed error
until time t.
The control law governing the flight path angle input u3 at some time t depends on which flight
mode the aircraft is in at that time. When the aircraft is performing a flight level change maneu-
ver (climb or descent), u3 directly controls the Rate of Climb or Descent (ROCD), corresponding to
h, maintaining a reference value ROCDref , read from BADA. Alternatively, when the aircraft flies
in cruise mode, the controlled variable is h, assuring the aircraft maintains the cleared flight level
href . As in the case of engine thrust control, a PI controller is used. The control law for u3 may be
mathematically summarized as:
u3(t) =
{kp3CDerocd(t) + ki3CD
∫ t0erocd(τ)dτ C/D
kp3CRZeh(t) + ki3CRZ∫ t0eh(τ)dτ CRZ
(2.46)
where
erocd(t) = ROCDref −ROCD(t) (2.47)
is the rate of climb error while performing a maneuver, and
eh(t) = href − h(t) (2.48)
is the altitude error. kp3CD and kp3CRZ are proportional gains, ki3CD and ki3CRZ are integral gains,∫ t0erocd(τ)dτ is the accumulated rate of climb error and
∫ t0eh(τ)dτ is the accumulated altitude error
until time t.
2.3.2.B Lateral control
Lateral control is concerned with the dynamics of an aircraft in the horizontal plane. In particular, it
focuses on controlling the aircraft heading, defining the way the aircraft turns and the horizontal path
it follows.
20
The equation governing the aircraft heading ψ may be found in equation system 2.28, and is
reproduced here:
ψ =CLSρ
2
v
msin(u2) (2.49)
Since the implemented model does not include rudder as a control input, heading is controlled
exclusively using the bank angle u2. A horizontal plane representation of an aircraft flying between
way points WPi and WPf , and the relevant variables for the u2 control law are shown in figure 2.6.
The point denoted CP corresponds to the point belonging to the great circle that is closest to the
aircraft at some instant. The two controlled variables are:
δGC(t) ≡ Cross track deviation from the great circle path
θh(t) = ψref (t)− ψGS(t) ≡ Heading error
where ψref (t) is the bearing at CP and ψGS(t) is the course angle, corresponding to the angle be-
tween ground speed vector vGS and true north. In the presence of cross wind, true airspeed vector v
and ground speed vector vGS are not alligned, and ψGS(t) differs from ψ(t).
vGS
WPi
WPf
N
Great circlereference path
Great circlebearing at CP
CP
ψGS
ψref
θh
δGC
ψref
Figure 2.6: Horizontal plane representation and relevant variables
The control law for bank angle u2 is then a function of δGC(t) and θh(t):
u2(t) = kpδδGC(t) + kpθθh(t) (2.50)
where kpδ and kpθ are proportional gains.
21
2.3.3 System discretization
With the exception of the equation governing an aircraft geographical position (which integration
was explained in section 2.2), every equation in the continuous-time system is discretized using a
fourth-order Runge-Kutta method. As mentioned before, system variables are indexed with a discrete
index k, i.e. t = kTs, where Ts is the integration time step. The time step used in this work was
Ts = 15 seconds.
2.4 Uncertainty modeling
A real ATC environment is highly non-deterministic, as many factors are unpredictable and the
number of involved variables is nearly unfathomable. This means that any automated system de-
signed to predict the future trajectories of aircraft inside a certain airspace must deal with uncertainty
on some level, in order for its predictions to be accountable and usable to provide safe advisories.
Common disturbances affecting trajectory prediction may be summarized the following way:
• ATCO operation
Air traffic flow peaks at specific hours may lead to situations of high workload for a specific
ATCO, which may compromise its ability to issue some instructions in due time and hence the
feasibility of a certain plan. A delay in instruction issuing is also possible in oceanic airspace if
a high frequency radio communication degradation occurs in some flight region.
• Aircraft operation
From the point of view of an automatic ATC system, the way in which a crew executes an issued
maneuver has a considerable level of uncertainty. The execution of the maneuver is affected by
the reaction time of the pilots and by the aircraft performance (which does not depend solely on
the aircraft model, but also, for instance, on the aircraft weight for a specific flight). There is also
the risk of non-compliance to a given instruction by some crew.
• Airspace/Airport disturbances
Unpredictable disturbances related with the available airspace may occur due to an airspace
restriction (usually for military use). Traffic predictions may also be disrupted in the event of a
closed airport (e.g. for safety, security or weather reasons).
• Weather phenomena
Two weather phenomena may have considerable effect on the predicted traffic.Wind may alter
significantly the 4D trajectory of an aircraft, especially in the situations where it blows in the
same direction as the aircraft – headwind or tailwind – and produces a change in its ground
speed. A storm that forms in the predicted path of some flight may force the ATCO to alter the
aircraft’s planned horizontal route and/or altitude in order to avoid the threat.
22
Enroute oceanic operation outside radar coverage is a particular case in which the lack of infor-
mation is dealt with by executing conflict-avoiding maneuvers well ahead of time (strategical planning
rather than tactical) and by increasing dramatically the horizontal separation criteria. Therefore, short
time scale disturbances affecting instruction issuing and maneuver execution are not critical, and are
assumed to be inexistent. This assumption excludes such uncertainty factors as high workload, radio
communication degradation, pilot reaction time and aircraft performance.
Certain factors may pose a serious threat to the air traffic flows predicted by ATC, but are not
modeled in this work. These factors include airspace restriction for military reasons, a closed airport
and the appearance of a severe storm at a certain region.
Wind, however, is accounted for in the present work: since aircraft fly at constant airspeed, strong
winds along the aircraft’s longitudinal direction may have considerable effect on ground speed, and
thus alter the Estimated Time of Arrival (ETA) at waypoints. Although the use of wind charts mitigates
the error and allows the calculation of reasonably accurate ETA at waypoints, wind was still introduced
as an uncertainty factor in the developed simulator.
An aircraft’s ground speed vGS depends on true airspeed v and wind w:
vGS = v + w (2.51)
The relation between the three vectors may be graphically shown using a wind triangle, as shown in
figure 2.7.
v
vGS
w
Figure 2.7: Relation between true airspeed, ground speed and wind vectors
A random wind vector may be introduced by defining two random variables: wind module wmod
and wind direction, ψw. Both variables are assumed to be normally distributed:
wmod ∼ N (w0, σ2w) (2.52)
ψw ∼ N (ψw0, σ2ψ) (2.53)
By adjusting the mean values, w0 and ψw0, and standard deviation parameters, σ2
w and σ2ψ, a wind
vector w is calculated. The components of wind vector w in a NED frame will be:
wN = wmod cosψw (2.54)
wE = wmod sinψw (2.55)
wD = 0 (2.56)
The choice of whether to generate aircraft trajectories deterministically (w = 0) or randomly (w 6=
0) depends on the phase of the algorithm in which the trajectories are being calculated. Further details
on uncertainty modeling are given in the next section.
23
3Conflict Detection and Resolution
The present chapter describes in detail the algorithm responsible for executing conflict detection
and resolution for a given traffic scenario. The ATC concepts needed to contextualize the CD&R
algorithm are presented in section 3.1, and the algorithm’s assumptions, restrictions, main definitions
and objectives are stated. The methods used for carrying out conflict detection are explained in
section 3.2. Section 3.3 presents the cost function needed to hierarchize the solutions and find an
optimal one. The branch-and-bound algorithm performing the necessary combinatorial optimization
is laid out in section 3.4. The concept of interactive multi-criteria decision making and its application
to the developed program are explained in section 3.5.
3.1 Fundamentals and objectives
Prior to describing how the Conflict Detection and Resolution algorithm works in detail, it is nec-
essary to present the main ATC concepts on top of which the algorithm was built. This is done in the
first part of this section (3.1.1).
The second part of this section (3.1.2) lays down the foundations for the development of the
algorithm. It focuses on the main assumptions used to construct the algorithm, the restrictions that
were introduced and the goals the algorithm must attain.
3.1.1 ATC context
In order to develop an accurate CD&R algorithm, an analysis must be conducted regarding the
main rules and procedures used by air traffic controllers to perform Conflict Detection and Conflict
Resolution in operational context. This analysis is presented in the present subsection. The spe-
cial case of Oceanic Airspace is also presented and the nuances of the control carried out in this
24
kind of airspace are indicated, serving as a basis for the assumptions for the algorithm construction,
presented in 3.1.2.
3.1.1.A Conflict Detection
In operational ATC context, a conflict is considered to occur between a pair of aircraft if, at some
instant, they violate certain separation minima. These criteria for separation may vary depending
on the airspace class the aircraft are flying in, on the instrumentation level and navigation capacities
of each aircraft, on whether the aircraft are inside or outside radar coverage, on country-specific
legislation, among other factors. The existence of a conflict does not necessarily imply an immediate
threat of collision between the involved aircraft, but is rather a safety net maintained by controllers
to account for navigational errors, unauthorized maneuvers executed by pilots and other unexpected
factors that may arise.
Two kinds of separation criteria are usually used in ATC: vertical separation and horizontal separa-
tion. In order for two aircraft to be safely separated, they must verify at least one of the two separation
criteria (vertical and/or horizontal). Separation rules are stipulated by ICAO and published in the Pro-
cedures for Air Navigation Services - Air Traffic Management (PANS-ATM) (usually referred to as doc
4444, and currently in its fifteenth edition [25]).
The vertical separation minimum is usually stipulated at 2000 ft or, in an airspace where Reduced
Vertical Separation Minima (RVSM) applies, 1000 ft. RVSM is a recent advance in ATC – made
possible by the high accuracy level with which aircraft measure and control their own altitude – has
been gradually implemented since 1999 and is now used at nearly a global scale. In particular, RVSM
rules are applied both in Lisboa Flight Information Region (FIR) and Santa Maria FIR – the two FIR’s
Portuguese jurisdiction – between FL290 and FL410.
Commonly used distances for horizontal separation in continental airspace include: 3 nautical
miles – in terminal areas, at slower speeds –, 5 or 6 nautical miles – used extensively for en route
traffic with good radar coverage – and 10 nautical miles – for en route traffic flying above a specified
horizontal distance from the radar antenna.
The separation distances described above may be represented graphically by defining a protected
zone around an aircraft, as shown in figure 3.1. The aircraft is placed at the center of a cylinder with
a radius equal to the horizontal separation distance SH and height corresponding to twice the vertical
separation distance SV . Separation is violated if, at some time, some aircraft enters another aircraft’s
protected zone.
For traffic in oceanic airspace (or, more generally, in airspace without radar coverage), rules for
separating aircraft are defined by the national aeronautical authority in charge of that airspace. In
this case, conventional procedural control is used, and controllers may ensure horizontal separation
using two methods: 1) distance separation – as is done in radar covered areas, only with a much
larger separation minimum, typically around 50 nautical miles; 2) time separation, monitoring the
time difference between two aircraft passing at some geographical point. Time separation may be
significantly easier to use by human controllers, and is usually applied in situations where two aircraft
25
SH
SV
SV
Figure 3.1: Aircraft protected zone
are flying the same route (where a 10 minute separation minimum is maintained) or routes that cross
at one point (in which case controllers must ensure the second aircraft does not cross that point less
than 15 minutes after the first one). These separation values for oceanic airspace are given merely
as examples, have been provided by air traffic controllers with operational experience in Santa Maria
FIR, and are not a standard.
3.1.1.B Conflict Resolution
In general, when an air traffic controller detects a potential conflict in the future between two
aircraft, he may resolve it by ordering the pilots to execute three kinds of maneuvers:
• Vertical: the ATCO instructs an aircraft to change from its current flight level to a different one.
The time at which the maneuver is to be executed may be specified by the controller (e.g.
immediately, before/after reaching a waypoint, at a given time);
• Horizontal: the controller instructs an aircraft to change its planned horizontal path. The de-
viation from the planned path may be specified in one of several ways: a new waypoint may
be added to the existing ones; an existing waypoint may be replaced by a new one; a new
heading may be followed temporarily by the aircraft; the aircraft may divert from the reference
path at some point (in order to resolve a conflict with nearby traffic) and return after a specified
time, some flown distance or when instructed by the controller; the aircraft may be instructed to
temporarily follow a path parallel to the current one, respecting some offset distance.
• Speed: the controller instructs one of the aircraft (or both) involved in the detected potential
conflict to increase (or decrease) its airspeed, in order to force the aircraft to pass at the pre-
dicted point of conflict at an earlier (or later) time. Usually, when two aircraft are involved in the
predicted conflict, if one aircraft is instructed to increase its airspeed, the other one is instructed
to decrease it, this way maximizing the separation time at the crossing point.
The choice of which kind of maneuver to use at a given situation may depend on a variety of
factors, that include:
• Geometry of the predicted conflict (e.g. whether the aircraft are flying parallel routes at same
26
direction, parallel routes at the opposite direction, nearly perpendicular routes at the point of
conflict)
• Time until the potential conflict occurs
• Probability of occurrence of an actual conflict
• Airspace type (e.g. whether the aircraft are in their en route phase, or inside terminal airspace)
• Radar coverage (whether the predicted conflict occurs within or outside radar coverage)
• Aircraft proximity from their top of descent
• Controller’s personal experience dealing with a specific airspace, traffic pattern, set of regular
flights, etc.
• Controller’s personal formation
3.1.1.C Special case: Oceanic Airspace
As mentioned and justified in the Introduction, the present work focuses on air traffic control ef-
fectuated in oceanic airspace. This premise means conventional procedural control rules apply: as
large portions of oceanic airspace are outside radar coverage, controllers rely on pilot reports to esti-
mate each controlled aircraft’s current position and do not receive real-time data of each flight, being
therefore unable to assess an aircraft’s compliance to an issued instruction.
This inability to access an aircraft position in real-time deters the extensive use of conflict-avoidance
maneuvers that require close monitoring by controllers, as is the case of the horizontal deviation ma-
neuvers commonly used in continental radar control. With no access to real-time aircraft position
information, controllers do not have an effective way of monitoring the conflict resolution maneuver
they issued.
As an example, we consider the situation depicted in figure 3.2, in which two flights – assumed
to be flying outside radar coverage – are shown: flight 1 flying eastbound and flight 2 flying in the
southwest direction. The controller in charge detects a potential conflict between the two aircraft and
decides to resolve it by applying a horizontal maneuver to flight 1. The maneuver consists of a first turn
of 30 degrees to the left, followed by a second turn to the right, to bring the aircraft back to its desired
path. The pilots must initiate each turn when instructed by the controller. Due to the unavailability of
radar image, the ATCO is unable to closely monitor the aircraft’s trajectory after the first turn, which
may prompt him to instruct the second turn too early (potentially compromising safety, by not resolving
the conflict with flight 2) or too late (forcing the aircraft to fly a longer path than needed, degrading
efficiency).
Speed change maneuvers are seldom used by ATCO in oceanic airspace, as well. This is due
mainly to two factors. On the one hand, the restrictions imposed by each aircraft’s flight envelope:
when cruising at some constant altitude, an aircraft can only safely fly inside a certain range of air-
speeds (bounded on the top for structural soundness reasons and on the bottom by some stall speed),
27
Flight 1
30o
Flight 2N
Turn 1
Turn 2
Predicted point of conflict
Figure 3.2: Conflict avoidance horizontal maneuver
and a variation in airspeed may only be safe, in some cases, if the aircraft descends to a lower flight
level. This limited range of airspeeds for a given aircraft at a specific altitude gives controllers a small
margin to work with, and to use speed change to resolve conflicts. On the other hand, speed change
maneuvers suffer from the same drawback mentioned above for the horizontal maneuvers: since
radar information is unavailable, the ATCO is unable to monitor the actual compliance to the issued
speed change maneuver and its effectiveness in solving the predicted conflict.
Most detected conflicts in oceanic airspace are then solved by controllers by issuing vertical in-
structions. Given a modern aircraft autopilot’s ability to measure and maintain a specified altitude,
placing two aircraft at different flight levels is a safe way to ensure they remain separated, even if
some uncertainty subsists over their horizontal position. After issuing a flight level change instruc-
tion to some aircraft, controllers in charge of oceanic airspace usually require the crew to report the
departure from the previous level and to announce the moment they reach the instructed final altitude.
A further remark must be made concerning oceanic control. Due to the fact that VHF communica-
tion (used for air-ground ATC communication in most continental airspaces) is limited to line-of-sight
range, high-frequency (HF) radio is used by oceanic control centers to establish communication with
aircraft flying outside VHF range.
HF radio communication is resorted to because its radio waves are reflected by the ionosphere
(a type of propagation called skywave) and are thus able to travel beyond the horizon and reach
long distances. Communication using this frequency band suffers, however, from some drawbacks.
High frequency signals are more prone to be affected by noise, which could render communications
using these signals temporarily unusable. High frequency noise sources may be of different natures:
atmospheric (thunderstorms), galactic (solar flares affecting the ionosphere’s reflecting properties,
and thus preventing skywave propagation) and man-made (e.g. caused by high voltages on power
transmitting lines). The use of good quality HF receivers and appropriate signal processing systems
somehow mitigates the effect of HF noise, but periods of high frequency communication degradation
still occur and may delay information transmission between controllers and pilots.
Another delay factor in oceanic control communications arises from the fact that no direct commu-
28
nication is actually established between controllers and pilots, but each transmission is rather carried
out by a radio operator working in an oceanic communication center, and acting as an intermediate.
The existence of this intermediate may delay the issuance of an ATC instruction by a controller (or
the subsequent transmission from the crew indicating the instruction has been executed), if the radio
operator responsible for transmitting is under heavy workload and busy at some specific time.
3.1.2 Proposed algorithm
3.1.2.A Assumptions and restrictions
For the reasons stated in 3.1.1, and given that this work is focused on the special case of oceanic
airspace control, the developed algorithm solves detected conflicts by resorting exclusively to vertical
instructions. This restriction means that, in any simulation, every aircraft flies according to the hori-
zontal route and true airspeed specified in its filed FPL, and only its altitude may be changed by the
ATCO for separation purposes.
Another key restriction is concerned with the time at which the algorithm is allowed to place instruc-
tions. Given that pilots are required to report their position to ATC each time an aircraft crosses a FPL
waypoint, and that communication between controllers and crew are infrequent beside the manda-
tory position reports, the algorithm is restricted to issuing instructions to an aircraft as it passes route
waypoints, and not at some arbitrary point in the aircraft path. This restriction respects the com-
mon practice at oceanic control, and allows the discretization of instruction issuing time, essential to
construct a solution search algorithm.
The problem is further discretized by the very nature of the procedures used in ATC. Since aircraft
fly at fixed flight levels (except when performing a climb or descent), a limited number of flight levels
are available for each aircraft, so long as a maximum flight level is defined. At each time, a maximum
altitude may be calculated for an aircraft, depending on such factors as the aircraft’s take-off weight,
fuel consumption, model and current engine performance. As fuel is consumed throughout the flight,
the aircraft’s weight decreases, as does the necessary lift force to maintain steady level flight, which
allows the aircraft to fly at a higher altitude, at thiner air. The controllers (and the projected algorithm)
are oblivious of the plane weight, and this maximum altitude may only be calculated precisely by
the aircraft’s FMS. The only maximum flight level value that can be safely used as a reference by
controllers is the model-specific service ceiling, indicated by the manufacturer, corresponding to the
maximum altitude at which an aircraft of some model may fly, regardless of the current conditions.
Hence, this is the value used by the proposed algorithm as an upper bound for an aircraft altitude.
A minimum flight level for each flight was also defined for the algorithm, corresponding to the
RVSM airspace lower bound used in Santa Maria FIR. This flight level is FL290, corresponding to an
altitude of 29000 ft.
Hence, the algorithm is designed to allocate an aircraft to flight levels between FL290 (the RVSM
airspace lower bound) and the service ceiling specified for that aircraft’s model.
29
3.1.2.B Definitions
Throughout the remainder of this thesis, an instruction issued by a controller to an aircraft with a
certain Callsign, ordering it to change its flight level from its present one to a destination flight level
FLdest when flying over a specified Waypoint, may be represented as:
I(Callsign,Waypoint, FLdest)
A flight plan is an immutable structure containing the information provided by the aircraft operator,
informing the controller (and the algorithm) of its desired route, flight levels and cruising airspeed.
Once it is accepted, a flight plan can not be changed at any point. A representation of a possible FPL
is as follows:
IBE123: A320 1047Z N0460F360 BANAL 43N020W/F370 43N030W 43N040W
This FPL indicates a crew operating an aircraft of model A320 with callsign IBE123 requests to enter
Santa Maria FIR at 1047 Zulu time, cruising at FL360, with true airspeed 460 kt. Its entry waypoint is
BANAL, and the following waypoints are 43N030W (geographical point located at latitude 43.0 degree
North, 30.0 degree West), 43N030W and 43N040W, where it abandons Santa Maria FIR. The suffix
/F370 indicates the crew plans to change its flight level to FL370 after crossing waypoint 43N020W.
Since no airways are defined for oceanic airspace, each aircraft always flies a direct route between
waypoints, hence the commonly used code DCT is not used.
The route requested by the FPL presented above may be represented graphically by drawing its
horizontal route (shown in figure 3.3 inside Santa Maria FIR) and its altitude profile (shown in figure
3.4).
20W25W30W35W40W 15W45N
40N
35N
30N
25N
20N
BANAL43N020W43N030W43N040W
Figure 3.3: Flight IBE123 horizontal route inside Santa Maria FIR
30
BANAL 43N020W 43N030W 43N040W
350
360
370
380
WP
FL
Figure 3.4: Flight IBE123 altitude profile
Since FPLs are immutable, changes for separation purposes are stored in a different structure,
corresponding to a current flight plan CPL. A CPL is a dynamic structure that can be changed anytime
between the acceptance of the flight plan and the aircraft departure from the controlled airspace.
Controllers change CPLs each time a change in route, flight level or airspeed is made, for any reason
(separation, weather, wind, etc.).
Due to the restriction that only vertical instructions are considered as conflict resolution maneu-
vers, a flight CPL can only differ from its FPL in the altitude profile. Therefore, a certain flight’s CPL
may be represented in this work simply by the altitude profile it imposes on that flight, as airspeed and
horizontal route remain equal to the ones stated in the FPL. Assuming a crew from a certain flight with
a certain Callsign had requested a horizontal route with Nwp waypoints, its CPL (denoted individual
plan) may be represented as a Nwp element flight level vector:
CPL(Callsign) = [FL1, . . . , FLNwp ]
Although the entry flight level cannot be changed by the ATCO operating on the considered
oceanic FIR (the controller simply accepts the aircraft at whichever level it is transfered from a neigh-
boring FIR), it is still included in the CPL altitude profile as the first element. This element may not be
changed, but its representation is useful to identify a maneuver executed at the entry waypoint.
As an example, the individual plan for flight IBE123, which FPL was presented above, may be
written as:
CPL(IBE123) = [360, 360, 370, 370]
admitting no changes were made to the FPL altitude profile.
If a certain flight i has a flight plan containing NWi waypoints, and its model-specific service ceiling
(represented as a flight level) is denoted SCi, the maximum number of levels NLi it may be assigned
to is calculated as:
NLi =SCi − 290
10+ 1 (3.1)
and the maximum number of possible individual plans for flight i is calculated as:
31
No of Individual Plans = NNWi−1Li
(3.2)
The set of individual plans for every flight of a given scenario is called a global plan.
If a scenario is composed by NA aircraft, the maximum number of possible global plans for that
scenario is given by the formula:
No of Global Plans =
NA∏i=1
NNWi−1Li
(3.3)
To provide insight on the dimension of the global plans state space, an example is given for simple
case. We suppose that, for some scenario, the following parameters are verified:
• NA = 2 flights
• NW1= NW2
= · · · = NW10= 4 waypoints
• NL1= NL2
= · · · = NL10= 13 possible flight levels
Since it was assumed, for simplicity, that every flight has a route with the same number of way-
points and that every aircraft has the same service ceiling (and thus the same number of flight levels),
equation 3.3 becomes:
No of Global Plans =
NA∏i=1
NNWi−1Li
= N(NWi−1)NALi
(3.4)
and thus the maximum number of global plans for the example given is obtained:
No of Global Plans = (13)(4−1)2 = 4826809 (3.5)
3.1.2.C Objectives
Having presented the necessary definitions, the objectives of the Conflict Detection and Resolution
module may be stated as follows. An optimization algorithm is to be developed that searches the set
of all possible global plans and selects an optimal one, that:
1. Generates conflict-free aircraft trajectories
2. Minimizes a Cost Function
3. Obeys restrictions imposed by controllers
The remainder of this chapter is concerned with the necessary tools to carry out these objectives.
Section 3.2 presents the Conflict Detection methods used by the algorithm. The Cost Function to
minimize is presented in section 3.3. Section 3.4 lays down the search algorithm responsible for
performing the combinatorial optimization over the global plans state space. The routine allowing
Interactive Multi-Criteria Decision Making (MCDM) between algorithm and controller is explained in
section 3.5.
32
3.2 Conflict Detection
Given that this work focuses on controlling en route traffic in Santa Maria FIR oceanic airspace,
RVSM rules are assumed, and thus the chosen separation minima are:
• Vertical Separation Minimum: SV = 1000 ft
• Longitudinal Separation Minimum: SH = 50 nmi
A conflict is detected in a simulation between the predicted trajectories of two aircraft at some
iteration k if their altitudes are within 1000 ft of each other and they are separated horizontally by less
than 50 nmi.
Henceforth, the horizontal distance between aircraft i and j at iteration k is denoted dH(i, j, k) and
their vertical separation is denoted dV (i, j, k).
Depending on the phase of the program at which it is executed, the conflict detection routine may
be of two kinds: deterministic and stochastic.
3.2.0.D Deterministic conflict detection
A deterministic conflict detection is carried out in the optimization phase of the algorithm, when
a solution is being sought. It is performed by generating a single deterministic trajectory per flight,
assuming no wind is present (w = 0). The program advances in time, and at each iteration calculates
the separation for each pair of aircraft in the given scenario. For a given pair of aircraft, i and j, at a
given iteration k, a conflict exists if and only if the following conditions are both verified:
dH(i, j, k) < SH (3.6)
dV (i, j, k) < SV (3.7)
3.2.0.E Probabilistic conflict detection
Whenever a plan that generates conflict-free trajectories for every aircraft in a given scenario
is found by the optimization algorithm (an algorithm which details will be given in section 3.4), it
is subjected to a robustness check – where uncertainty introduced by wind is accounted for – that
consists in executing a probabilistic conflict detection routine.
This is accomplished in the following way: a Monte Carlo simulation is ran, in which several parti-
cles are created for each flight and different trajectories are calculated by adding a randomly gener-
ated wind vector to each particle. As explained in section 2.4, wind is modelled assuming a Gaussian
distribution. The conflict-free calculated plan is applied to every particle independently.
In this case, each flight’s trajectory has a random component, which motivates the introduction
of the concept of conflict probability, in order to mathematically define how likely a conflict between
a pair of aircraft i and j is to occur, at a certain instant k. This conflict probability assumes a value
between 0 and 1 (where 0 indicates an impossible event and 1 indicates a certain event) and is
denoted pC(i, j, k).
33
At a given time, the algorithm runs pairwise conflict detection, as represented in figure 3.5. Given
two aircraft i and j, the number of conflicts Nc may be found by testing every possible pair of particles
from i and j. Let Np be the number of particles for each aircraft, the number of combinations is N2p .
Then, similarly to what is done in [26], the conflict probability between aircraft i and j is estimated by
the formula:
P (Cij) =NcN2p
(3.8)
A potential conflict is assumed to exist between i and j if P (Cij) exceeds a threshold probability pthr.
In that case, the plan is rejected.
pairwise tests
Flight i particles
Flight j particles
Figure 3.5: Particle by particle stochastic conflict detection
Conflict probability calculated in the above manner has a resolution equal to 1N2p
, so the number
of particles Np must be increased in order to obtain lower resolutions and to be able to detect conflict
scenarios with a lower conflict probability.
3.3 Cost Function
The task of surveying the set of all possible global plans for a given scenario and selecting an
optimal one to present to the human controller can only be carried out by the CD&R algorithm if some
way to qualify and rank the plans is defined without ambiguity. Ranking of plans is achieved in this
work by assigning each plan a cost and the optimal plan for a given scenario is selected as the one
with the lower cost.
In 3.3.1, several possible criteria to be taken into account when calculating the cost of a plan are
presented, and the choice of the criteria used in this work is justified. The way the selected criteria
are combined to define the Cost Function formula is described in 3.3.2.
3.3.1 Criteria selection
When faced with the task of performing conflict resolution on a scenario in which a potential con-
flict was detected in the future, a human controller must select a course of action between a set of
possibilities that he formulates based on his formation and operational experience. Being unable to
accurately predict the medium- and long-term consequences of each resolution strategy, controllers
often opt to follow a conservative solution, that primarily favors safety (as all CD&R human and com-
puterized agents must do) and that places an emphasis on reducing the controller’s workload. This
34
reduction in workload may be achieved by applying resolution strategies that solve the predicted con-
flicts using a small number of instructions (and thus a small number of air-ground communications)
and/or using instructions issued as early as possible, reducing the amount of time spent on solving
the detected conflict and freeing the controller to perform other tasks.
It is useful to introduce here the concept of efficiency, as defined by Krozel et. al. in [11]. Efficiency
is a measure of how closely an aircraft flies its desired flight plan. Given that this work deals solely with
vertical resolution maneuvers, the only deviation from the preferred trajectory will be on the vertical
plane, and thus a plan is efficient in the sense described early if an aircraft flies at the requested flight
level for each route leg.
If a controller is working close to his maximum workload, his resource management may have
considerable negative effect on efficiency, since he may choose to instruct the pilots to fly at an
altitude lower than the optimal one – potentially penalizing the aircraft by increasing fuel consumption
– to minimize their own workload. This is yet another motivation to the development of a CD&R
decision support tool, since such an instrument may help the controller select more efficient (and
user friendly) solutions, while maintaining (or even reducing) the controller’s workload.
It is then clear that the CD&R algorithm must account for both controller workload and efficiency
when assigning a cost to each calculated global plan. This is done by defining a cost function de-
pending on two criteria: number of instructions issued by the ATCO and deviation integral between
the preferred trajectory and the flown trajectory imposed by the global plan.
Several other criteria might be suitable for evaluating plans in ATC automation systems but were
placed aside in this work, for different reasons. Time delay could be measured by predicting the
amount of time a certain aircraft takes to fly across the controlled FIR if a certain plan was to be
applied. Its relevance comes from the fact that delays on arrival may have considerable economic
effect on commercial airlines. However, the ATC maneuvers with the higher potential for provoking
time delays are the ones that alter the horizontal motion of the aircraft: horizontal route change (forcing
an aircraft to fly a longer distance, at the same speed) and speed change (forcing an aircraft to fly the
same distance, at a lower speed). Flight level change maneuvers have little effect on time delay, so
this criterion was abandoned.
Another suitable criterion to minimize might be fuel consumption. Reducing fuel consumption has
a strong economic effect on airlines and is also environment friendly, since it reduces the emission of
greenhouse gases, such as CO2. However, explicitly calculating an aircraft’s estimated fuel consump-
tion for a given route is a difficult task to be carried out by a ground system, since fuel consumption
depends on a variety of factors that are unknown by the algorithm, such as aircraft weight and engine
performance at different altitudes. Thus, fuel consumption is not estimated in this work, and its reduc-
tion is achieved by minimizing the vertical deviation from the filed flight plan. In practice, this means
the algorithm leaves the task of selecting the most fuel efficient altitude to the crews and tries to follow
the requested altitude profile as closely as possible.
35
3.3.1.A Number of Instructions
Including in the cost function the total amount of instructions (denoted N ) issued by a controller
within a certain time window serves the purpose of keeping the ATCO workload inside a bearable
level. Since all issued maneuvers require two-way communication through the radio operator – trans-
mission of the instruction and reception of the pilot readback –, a certain time period is dedicated
to each instruction issuing by the controller. If many instructions (and thus air-ground communica-
tions) are required from the ATCO at some traffic peak situation, the total amount of time dedicated
to communication may overwhelm the controller and compromise its ability to execute its remaining
duties.
When counting issued instructions, no distinction is made in this work between climb and descent
instructions or between instructions with different vertical distance from the initial to the final flight
levels. Every instruction is worth the same, since every instruction requires the same resources from
the human controller.
3.3.1.B Deviation Integral
In order to minimize the distance flown by an aircraft in a flight level other than the one requested
on the FPL (and thus to minimize the fuel consumption on that route segment), the vertical deviation
from the flight plan is measured and included in the cost function as a deviation cost D. This is done
by calculating a deviation integral (denoted I), which consists of the area (hence the term integral)
between the filed FPL trajectory and the trajectory that is actually flown as instructed by ATC.
As an example, we consider again flight IBE123 mentioned in section 3.1.2, with FPL:
IBE123: A320 1047Z N0460F360 BANAL 43N020W/F370 43N030W 43N040W
The crew operating this flight has requested to enter Santa Maria FIR at waypoint BANAL at flight
level FL360, and plans to perform a step climb to flight level FL370 when passing waypoint 43N020W
(presumably due to the prediction that, by that time, the weight of the aircraft will be such that FL370
is a more fuel efficient altitude than FL360). We suppose a potential conflict is detected between
flight IBE123 and some other aircraft and that the algorithm calculates a resolution plan in which this
conflict is solved by ordering flight IBE123 to perform the step climb at waypoint 43N030W instead
of waypoint 43N020W (i.e. the aircraft is held at a lower flight level than requested during the route
segment between 43N020W and 43N030W ). Then, the deviation integral for flight IBE123 if this
specific plan is to be applied is as shown in figure 3.6.
The blue line indicates the altitude profile requested in the FPL, the red line indicates the trajectory
change imposed by the conflict resolution plan and the shadowed area corresponds to the deviation
integral. This integral depends directly on the distance between waypoints 43N020W and 43N030W
and on the vertical distance between filed flight level and flown flight level (in this case, between FL360
and FL370, i.e. 1000 ft).
Some considerations must be made regarding the method used in this algorithm to account for
the case in which ATC instructions order aircraft to fly above the requested flight level. In general, the
36
350
360
370
WP
FL
BANAL 43N020W 43N030W 43N040W
380
FPL CPLDeviationintegral
Figure 3.6: Deviation Integral illustration for flight IBE123
flight levels indicated by the crew for each route segment are never exceeded in operational context.
Prior to the flight, calculations are carried out to estimate an optimum cruise level, that depends on the
number of passengers, the predicted luggage weight, the predicted fuel consumption, the predicted
wind at different altitudes, the aircraft empty weight, among other factors. Flying below that flight
level is inefficient, since fuel consumption increases, and flying above it is unsafe, since the additional
decrease in air density may cause the aircraft to fly too close to its coffin corner and to be unable to
produce the necessary lift.
In certain cases, however, the crews may accept – or even request – flying at a higher altitude
than the one stated in the FPL. This may be due to the aircraft having taken off with a lower takeoff
weight than predicted or to the occurrence, at certain altitudes, of winds of different direction and/or
different module from those on the weather forecast, which leads the aircraft’s FMS to calculate a
different optimum level from the one calculated for the FPL.
Given that the CD&R decision support tools (along with the controllers) is unaware of the inter-
nal calculations of each aircraft’s FMS, it cannot be safely ascertained, without querying the pilots,
whether an aircraft may fly above its FPL flight level at any given point.
A possible approach to deal with this uncertainty would be to rule out altogether the possibility
of placing flights above the FPL flight level, thus solving every detected conflict by ordering aircraft
to fly below it. This would be a safe approach to the problem, as it would create trajectories that
would never be unflyable by the aircraft, but it would also be a inefficient one, never exploring sets of
solutions that are potentially more efficient, and still feasible.
The problem was dealt with using a different approach: the algorithm explores solutions that place
aircraft above their FPL requested flight levels, but only within a certain tolerance, defined by the user.
For instance, if the user – the ATCO being assisted by the support tool – sets the tolerance as 2, the
algorithm searches for trajectories in which aircraft fly no more than 2 flight levels above FPL route,
so an aircraft that had requested FL360 in its FPL is placed no higher than FL380.
The situations in which the algorithm generates trajectories that place aircraft above FPL flight
levels are explained in detail when the branch-and-bound algorithm is presented, in section 3.4. It
37
must be made clear, however, how the cost is calculated for such trajectories.
For the deviation cost calculation to be explained, the cruise portion of a flight is split into two
phases. As an illustration, we assume a flight with callsign TP007 has the following FPL through
Santa Maria FIR:
TP007: A320 0720Z N0460F350 30N040W 35N035W/F360 40N030W/F370 40N020W/F360 ER-
PES
The altitude profile and flight phases for flight TP007 are depicted in figure 3.7. Up until the first
waypoint at which the flight is planned to execute a descent (40N020W ), the aircraft is here considered
to be flying the climb phase. From that waypoint onwards, the aircraft is considered to be flying the
descent phase. If a flight does not have a planned descent inside Santa Maria FIR (the commonest
case, since the vast majority of flights flying in Santa Maria FIR is crossing it, rather than landing on a
closeby airport), it is assumed to remain in the climb phase throughout the FIR.
This breakdown of the cruise portion of the flight is key, since the deviation cost D will be calculated
differently depending on the phase the aircraft is flying.
Climb phaseDescentphase
First descent350
360
370
WP
FL
30N040W 35N035W 40N030W 40N020W ERPES
Figure 3.7: Altitude profile and flight phases for the cruise portion of flight TP007
If an aircraft is at the climb phase of its flight, the deviation cost for a positive deviation from the
FPL altitude profile (FL− FLFPL > 0) is null, i.e. D = 0. This serves two purposes:
1. By making D = 0 for route legs with a positive deviation, the algorithm evaluates equally the
trajectories at the FPL altitude and the ones with altitudes above it. From the point of view of the
algorithm, the aircraft is not penalized by flying at a higher altitude than the one requested, as it
should be expected.
2. When an aircraft is already flying above its requested flight level, a positive value of the deviation
cost (D > 0) would lead the algorithm to descend the aircraft to that level, which is undesirable.
The latter situation is illustrated in figure 3.8. We suppose at some point in the simulation, flight
TP007 is at waypoint 35N035W, flying at FL370 (the point denoted Current position in the graphic). If
38
350
360
370
WP
FL
30N040W 35N035W 40N030W 40N020W ERPES
I > 0
D > 0
Undesirabledescent
Current position
(a) D > 0
350
360
370
WP
FL
30N040W 35N035W 40N030W 40N020W ERPES
I > 0
D = 0
Current position Desirable hold
(b) D = 0
Figure 3.8: Illustration of the effect of cost deviation D on the climb phase of flight TP007
we were to assume a deviation cost D > 0 for the route segment between 35N035W and 40N030W
(since current level FL370 is higher than FPL level FL360), the algorithm would be prompted to issue
a descent instruction of 1000 ft at 35N035W, as shown in 3.8(a). That would clearly be an undesirable
instruction, given that the crew of flight TP007 has already accepted to fly at FL370. From the point
of view of the algorithm, there is no indication that flight TP007 would benefit from such instruction,
hence it should be maintained at FL370, as shown in 3.8(b), which is achieved by making D = 0.
On the other hand, if an aircraft is flying its descent phase, the deviation cost D for a positive
deviation may no longer be zero. As an illustration, we consider the situation depicted in figure 3.9.
We suppose at some point in the simulation, flight TP007 is at waypoint 40N020W, flying at FL370.
If we were to assume the deviation cost to be D = 0 for the route segment between 35N035W and
40N030W (i.e. if we were to attribute no cost to the deviation between FPL level FL360 and current
level FL370), the algorithm would be prompted to hold flight TP007 at its current level FL370, as
shown in figure 3.9(a), clearly an undesirable decision. The correct decision – to the extent of the
algorithm’s knowledge – would be to instruct the aircraft to descend to FL360, as requested in the
39
350
360
370
WP
FL
30N040W 35N035W 40N030W 40N020W ERPES
I = 0
D = 0
Current position Undesirablehold
(a) D = 0
350
360
370
WP
FL
30N040W 35N035W 40N030W 40N020W ERPES
I = 0
D > 0
Desirabledescent
Current position
(b) D > 0
Figure 3.9: Illustration of the effect of cost deviation D on the descent phase of flight TP007
flight plan. This is achieved by making D > 0, as shown in figure 3.9(b).
The above explanation illustrates the need to make D > 0 for the descent phase of a flight, but
there remains the question of distinguishing between symmetric trajectories around the FPL level, i.e.
between a trajectory with a positive deviation (FL−FLFPL = d > 0) and a trajectory with a negative,
and symmetric, deviation (FL−FLFPL = −d < 0), where d is some deviation measured in hundreds
of feet. The problem is illustrated in figure 3.10, where it is still assumed that flight TP007 has reached
40N020W, flying at FL370. If the deviation cost D was to be calculated in the same way for both cases
– for instance by making D = I – the same deviation cost would be obtained, i.e. Dup = Ddown, since
the symmetric trajectories would yield Iup = Idown. This would cause the algorithm to attribute the
same cost due to vertical deviation to both trajectories, this way assuming both trajectories penalize
the flight equally. This is obviously not the case, since the aircraft crew would rather fly at the higher
of the two trajectories, saving fuel.
It is then clear the deviation cost for a positive deviation must assume a positive value (D > 0), but
still a lower value than the one assigned to a trajectory with a negative deviation. The choice was to
40
350
360
370
30N040W 35N035W 40N030W 40N020W ERPES WP
FL
d
d
Iup
Idown
FL > FLFPL
FL < FLFPL
Figure 3.10: Symmetric trajectories around FPL for the descent phase of flight TP007
make Ddown = I and to apply a 12 multiplicative factor to Dup:
Dup =1
2Ddown =
1
2I (3.9)
The calculation of deviation cost D between those waypoints depending on the deviation sign
(above/below FPL) and on flight phase may be summarized as shown in figure 3.11.
Above FPL
Below FPL
Climb phase
Descent phase
(FL − FLFPL > 0)
(FL − FLFPL < 0)
D = 0
D = 12I
D = I
Figure 3.11: Deviation cost D calculation depending on deviation sign and flight phase
3.3.2 Cost calculation
Let [WP1, . . . ,WPNw ] be a FPL route containing Nw waypoints. For an aircraft j flying between
waypoints WPi and WPi+1, the deviation integral is:
Ij,WPi−WPi+1=
∫ WPi+1
WPi
(FLFPL − FLATC)ds (3.10)
Assuming flight j has a FPL route containing Nw waypoints, its total deviation cost is the sum of
the deviation costs for each segment of its route:
Dj =
Nw−1∑n=1
Dn (3.11)
41
where Dn is the deviation cost for route segment n. The total deviation cost for a global plan solving
a scenario with Nf flights is the sum of every individual flight deviation costs:
Dtotal =
Nf∑j=1
Dj (3.12)
Finally, assuming that plan is composed of NI instructions, a linear cost function may be defined
as follows:
f = λNNI + λDDtotal (3.13)
where λN and λD are weight coefficients. These parameters may be adjusted to favor one of the
criteria over the other. Setting λN � λD will cause the algorithm to instruct aircraft to fly as closely
to their FPL as traffic allows, no matter how many instructions it takes, whereas letting λN � λD will
favor the choice of plans with as few instructions as possible, disregarding vertical deviation from the
requested flight levels.
When a cost function with two or more criteria is to be minimized by an algorithm – a multi-criteria
decision making problem – the concept of optimal solution is replaced by that of Pareto optimal solu-
tion, of which many may exist for a given scenario. Different approaches may be followed regarding
the way in which these Pareto optimal solutions are calculated and how much involvement from the
decision maker (in this case, the controller) takes place. In order to simplify the exposition of the pro-
posed algorithm, the combinatorial optimization routine is presented at first, in section 3.4, assuming
a fixed ratio λNλD
between weight coefficients, i.e. assuming the relative importance of both criteria is
previously stipulated. In practice, this is a single-criteria optimization algorithm. Then, in section 3.5,
the choice of an interactive solution for the multi-criteria decision making problem is justified and its
implementation is described.
42
3.4 Combinatorial Optimization
3.4.1 Algorithm overview
In order to find the optimal solution for a given problem (the solution with the minimum cost for
some ratio λNλD
), a search algorithm following a combinatorial approach was adopted. On a high level,
the search algorithm may be schematically represented as in figure 3.12.
As input, the implemented search algorithm receives:
• Scenario: the flight plans for every aircraft scheduled to fly over the controlled FIR within the
simulation time window
• λN
λD: the criteria weight ratio
• Nmax: restriction introduced in criteria N
• Dmax: restriction introduced in criteria D
SearchalgorithmScenario CPLopt
λNλD
Nmax Dmax
Figure 3.12: Search algorithm high level overview
The way in which restrictions Nmax and Dmax are generated will be explained in section 3.5. By
now, it suffices to say that they work as upper bounds, imposed by the ATCO, for the cost function
criteria, which means that the output plan cannot contain more than Nmax instructions and may not
generate a deviation higher than Dmax on the scenario flights.
The output of the algorithm consists of a single element:
• CPLopt: the optimal plan for ratio λNλD
The search is performed by a branch-and-bound algorithm, with a depth-first configuration. This
means the algorithm expands just one branch at each node n and proceeds to analyze its successor
n′, leaving the remaining branches unexplored and stored for an eventual return later. This way, the
algorithm attempts to find a terminal node in as few steps as possible. Since the depth of the search
tree is bounded (being a function of the number of flights in the scenario), there are no infinite paths
for the algorithm to follow, this way averting one drawback depth-first algorithms often suffer from.
The implemented algorithm verifies two important requirements:
• Optimality: as already mentioned, the algorithm is guaranteed to find the optimal solution to
the problem (possibly at the expense of dramatically increasing the computation time, for some
scenarios)
43
• Completeness: the algorithm finds a solution to the problem, provided at least one exists
3.4.1.A Nodes
The search method implemented in this work advances progressively in time, and creates a node
each time some flight k passes by some waypoint of its route. Since instructions are always placed
on route waypoints, these are the points in time at which branch must take place, i.e. at which the
possible courses of action must be enumerated and evaluated. The time at which flight k is predicted
to pass by its waypoint WPk[i] is denoted tk,i.
For every node n, a path-cost g(n) may be calculated. This corresponds to the cost of the plan
calculated so far, i.e. to the cost of the plan before some decision is taken at node n. This cost is
calculated according to the cost function introduced in 3.3.2.
Advancing from a node n to a successor n′ consists of 2 phases, as shown in figure 3.13:
1. Branch: generation of set of branches corresponding to a set of possible actions
2. Trajectory prediction: generation of the predicted trajectory for flight k between waypoints
WPk[i] and WPk[i+ 1], according to the chosen branch
FLmin FLmax. . .
FLmin + 10 FLmax − 10
f(n′1) f(n′2) f(n′b)f(n′b−1)
n
Phase 1: Branch
Phase 2: Trajectory prediction
g(n)
n′1 n′2 n′bn′b−1
Figure 3.13: Expansion of successors n′ of node n
The difference between generating and expanding a successor node must be explained, in the
context of this work. In Phase 1 of 3.13, nodes are generated : they are enumerated, the ATC in-
structions to which they refer are identified and their cost is calculated. Only in Phase 2, after the
trajectory is calculated, is a node considered to have been expanded. This distinction is essential,
since generating a node and expanding a node require different computational efforts, both in time
consumed and used memory.
44
3.4.1.B Branch
At each node n, branches are generated by enumerating the possible decisions to be taken upon
flight k at that node. Since only vertical instructions are considered, possible decisions to be taken
concerning flight k may represented by the flight level at which that flight may be placed as a result of
that decision. Hence, the list of b generated branches at node n may be represented as a list of flight
levels containing all the levels between a minimum (FLmin) and a maximum (FLmax):
Branchesn = [FLmin, FLmin + 10, . . . , FLmax − 10, FLmax] (3.14)
and
b = FLmax − FLmin + 1 (3.15)
Alternatively, the list of generated branches may also be represented by the list of ATC instructions
that take the aircraft from its current flight level to the final flight level:
Branchesn = [i1, . . . , ib] (3.16)
As mentioned before, the minimum flight level at which any aircraft may be place is given by the
lower limit in RVSM airspace:
FLmin = FL290 (3.17)
In this work, the maximum flight level for an aircraft on some route leg depends on whether the
instruction being calculated is resolving a conflict or not.
If a conflict is being resolved (conflict resolution mode), the algorithm allows the aircraft to be
placed above its requested flight level, and hence the maximum flight level FLmax depends on the
FPL flight level for that route leg (FLFPL), on the aircraft model’s service ceiling (SC) and on the
defined tolerance for aircraft above requested altitude (DT ):
FLmax,CR = min(SC,FLFPL +DT ) (3.18)
If, on the other hand, no conflict is being resolved (regular mode) the algorithm does not allow the
aircraft to be placed above its requested altitude, and thus the maximum flight level FLmax is simply:
FLmax,reg = FLFPL (3.19)
The implemented algorithm works in a best-first approach, which means branches in a given node
are expanded in ascending order of cost. To achieve this, each successor n′j is assigned a cost:
f(n′j) = g(n) + h(n′j) (3.20)
in which h(n′j) is a heuristic function that estimates the cost of the path from node n to a solution,
assuming the algorithm chooses successor n′j to proceed the search, i.e. assuming branch j is
selected.
It is crucial for the chosen heuristic h(n′) to verify two conditions:
45
• Admissibility : the heuristic is admissible if it never overestimates the cost to reach a solution
• Consistency : the heuristic is consistent if it never originates a pair of consecutive nodes (a
parent node n1 and a child node n2) in which the child node has a lower cost than the parent
node (f(n2) < f(n1))
By requiring the heuristic to be admissible, the algorithm is guaranteed to be optimal, whereas
requiring it to be consistent implements a search in which total cost f(n) is non-decreasing as a path
is followed from the initial state to a solution. A corollary of this result is the following: if a node n
in the middle of the search tree has a cost f(n), each one of its descendants will have a cost f(nd)
equal to, or higher than its own cost (f(nd) ≥ f(n)). This result is important since it allows pruning to
be executed in the search tree.
The heuristic function implemented in this work works in the following manner. A depth-first search
is started at node n, follows successor n′j and finds the optimal plan to reach a solution, running no
conflict detection. It does not execute any trajectory prediction, and assumes all aircraft to fly a
nominal great circle path between fixes (essential to assure the admissibility of the heuristic). The
calculated cost of this optimal path from node n through successor n′j to a solution corresponds to
the heuristic function for branch j, h(n′j).
By calculating the heuristic function for every branch originating from node n, the algorithm is able
to compute their total cost f(n′j), and may choose the successor with the lower total f to expand at
each time.
An important point must be emphasized: each cost f(n′) assigned to a successor of node n is
calculated prior to the generation of the trajectory associated with that successor. This is crucial,
since it allows the algorithm to estimate the cost of every successor without having to expand them,
thus being able to expand first the ones that may lead to a solution with a lower cost. This is why, in
figure 3.13, the total cost f(n′) is placed after the branch phase, and not after the trajectory prediction
phase.
3.4.2 Algorithm structures
3.4.2.A The node structure
To represent a node n in the implemented algorithm, a structure was created that contains all the
information needed by the algorithm to proceed the search from that node. In particular, this structure
contains the information indicating what the current situation is (the plan and trajectories that have
already been calculated by the ancestors of node n) and the information the algorithm needs to
generate its own successors (the possible instructions generated by branching node n).
A structure of node n contains the following fields:
46
n =
Aircraft(n)WP(n)t(n)
ETA(n)NextWP(n)
CPL(n)N(n)D(n)
Expanded(n)Unexpanded(n)
fex(n)fun(n)
(3.21)
• Aircraft(n): the identification of the aircraft to which the node n refers
• WP(n): the waypoint at which Aircraft(n) arrives
• t(n): the time at which Aircraft(n) reaches WP(n)
• ETA(n): a vector containing the estimated time of arrivals of every flight in the scenario at their
next waypoints
• NextWP(n): a vector containing the identification of the next waypoint for every flight in the
scenario
• CPL(n): the overall plan calculated up until node n has been reached
• N(n): the number of instructions N contained in CPL(n)
• D(n): the deviation D caused by CPL(n)
• Expanded(n): a list containing the successors of n that have already been expanded
• Unexpanded(n): a list containing the successors of n that have not been expanded yet
• fex(n): a list containing the cost f for each expanded successor of n
• fun(n): a list containing the cost f for each unexpanded successor of n
To store the information relative to all nodes that have been expanded at some point by the search
algorithm, a structure called NodesStack is created. Nodes are stacked on top of each other, hence
the node at the bottom of the stack is, at all times, the Root node of the search tree, and the node at
the top is the Active node. Each element of this stack contains all the elements described above for
the node structure. The dimension of structure NodesStack is, at each point of the algorithm, equal
to the current depth of the search tree.
It is worth explaining that the lists Unexpanded(n) and Expanded(n) do not actually contain the
successor nodes for each branch of n, but rather the action that leads node n to its successor n′, i.e.
the ATC instruction that each branch represents.
Figure 3.14 shows an example, in which each node has a branching factor b = 4. The current
search tree has a depth of 3, hence that is the dimension of NodesStack. In nodes n1 and n2,
47
a decision has already been taken, i.e. an instruction has been expanded (respectively i1,2 and
i2,3), thus these instructions have been moved from the Unexpanded to the Expanded lists of their
corresponding nodes. In node n3, however, 4 instructions have already been generated by branch,
but none has been chosen to expand yet, hence Expanded(n3) is empty.
Since an overall plan CPL(n) represents the path that has lead to node n, CPL(n1) is an empty
list, because n1 is a root node. In nodes n2 and n3, CPL(n) contains the list of instructions that have
been chosen in order to reach each node.
n1
n1
NodesStackn2
n3
n2
n3 Active node
Root node
i3,1i3,2 i3,3
i3,4
i2,1i2,2 i2,3
i2,4
i1,1i1,2 i1,3
i1,4
CPL(n1) = []
Unexpanded(n1) =[i1,1 i1,3 i1,4
]Expanded(n1) =
[i1,2
]
CPL(n2) =[i1,2
]Unexpanded(n2) =
[i2,1 i2,2 i2,4
]Expanded(n2) =
[i2,3
]
CPL(n3) =[i1,2 i2,3
]Unexpanded(n3) =
[i3,1 i3,2 i3,3 i3,4
]Expanded(n3) = []
n1
n2
n3
Figure 3.14: Example of search tree with depth 3, with respective stack of nodes
3.4.2.B The FPL structure
All in the information about an aircraft’s flight plan is contained in its FPL structure. The FPL
structure of some flight k contains the following fields:
FPLk =
tentryRoute
FLProfileTAS
ModelParameters
(3.22)
• Route: sequence of fixes describing the flight’s route
• FLProfile: sequence of flight levels describing the flight’s altitude profile
48
• TAS: requested airspeed for the flight
• ModelParameters: the parameters describing the aircraft’s performance, read from BADA
In each simulation, a variable denoted Scenario is created, containing a list of FPL structures for
all NF flights:
Scenario =
FPL1
FPL2
. . .FPLNF
(3.23)
3.4.3 Algorithm description
3.4.3.A Main function
Algorithm 1 presents a pseudo-code representation of the branch-and-bound algorithm.
The structure that effectively controls the algorithm, advancing and retreating in time, and defining
which node to analyze at each iteration, is NodesStack. A loop is implemented, that at each iteration
picks the topmost node (i.e. the most advanced in time) from the stack to proceed the simulation.
After picking a node n to analyze, the algorithm verifies whether all successors of n have already
been expanded. In the affirmative case, node n is deleted from the top of the stack and the loop
continues to next iteration.
If there are still unexpanded successors in n, the algorithm performs the bound check. The mini-
mum cost of any unexpanded node is checked to be lower that current upper bound fmin, and criteria
N(n) and D(n) are compared with restrictions Nmax and Dmax. If any of these parameters exceeds
its bound, node n is discarded from NodesStack and the algorithm goes back to the top of the loop.
None of the conditions being verified means there is at least one successor of n with a cost
f(n′) < fmin that may lead to a feasible optimal solution. The algorithm chooses the unexpanded
successor with the lower cost f to expand, and uses the corresponding instruction to predict the
trajectory of Aircraft(n) between its current waypoint and its next waypoint.
A deterministic conflict detection routine is then performed on the calculated trajectories between
current node time t(n) and next node time t(n′). If a conflict is detected, at some time, between two
flights A and B, the algorithm analyzes the stack of nodes, and deletes every topmost node until it
finds one referring to flights A or B, then returning to the top of the loop.
If the deterministic conflict detection indicates no conflicts were found, the algorithm checks the
possibility of current node n being a terminal node. Node n is identified as a terminal node if one of
two conditions is verified:
1. Trajectories completed: all flights have already flown the complete route stated in their FPL
2. Elapsed time: the time predicted for the next node falls outside the defined simulation time
window
If n is indeed a terminal node, a robustness check, executing probabilistic conflict detection on the
trajectories, is carried out. If a conflict is detected by the robustness check, the algorithm backjumps
49
Algorithm: Optimization()input : Scenario,λNλD , Nmax, Dmax
output: CPLopt
1 Initialize NodesStack as empty2 Initialize CPLopt as empty3 fmin =∞
4 n← Create First Node(Scenario)5 Branch(n,Scenario)6 Put n on top of NodesStack
7 while NodesStack not empty do
8 n← Pick topmost element from NodesStack
9 if Unexpanded(n) is empty then10 Delete n from NodesStack11 Continue to next iteration12 end13 if min(fun(n)) > fmin or N(n) > Nmax or D(n) > Dmax then14 Delete n from NodesStack15 Continue to next iteration16 end17 i← argmin(fun(n))18 Update Node(n, i)
19 CPL(n′)← CPL(n) + i
20 Trajectory,ETA(n′),NextWP(n′),t(n′)← Predict Trajectory(Aircraft(n),WP(n),textitCPL(n′))21 FlightData(n′)← FlightData(n)+ Trajectory
22 ConflictReport ← Conflict Detection(FlightData(n′),t(n),t(n′))
23 if ConflictReport contains conflict between A and B then24 Backjump(NodesStack,ConflictReport)25 Continue to next iteration26 else27 if n is terminal node then28 ConflictReport ← Robustness Test(Scenario,CPL(n′))29 if ConflictReport contains conflict between A and B then30 Backjump(NodesStack,ConflictReport)31 Continue to next iteration32 else33 SolutionCost ← Compute cost for overall plan CPL(n′)34 if SolutionCost < fmin then35 fmin ← SolutionCost36 CPLopt ← CPL(n′)
37 else38 Delete n from NodesStack39 Continue to next iteration40 end41 end42 else43 n′ ← Create New Node(CPL(n′),ETA(n′),NextWP(n′),t(n′))44 Branch(n′,Scenario)45 Put n′ on top of NodesStack46 Continue to next iteration47 end48 end49 end
50 Return CPLopt
Algorithm 1: Main function50
Unexpanded(n) Expanded(n)
fun(n) fexp(n)
S1 S2 S3 S4 S5 S6 S7 S8
f1 f2 f3 f4 f5 f6 f7 f8
min(fun(n))
argmin(fun(n))
(a) Choice of successor to expand
Unexpanded(n) Expanded(n)
fun(n) fexp(n)
S1 S2 S3 S4 S5 S7 S8
f1 f2 f3 f4 f5 f7 f8
S6
f6
(b) Update successors lists
Figure 3.15: Example of successor expansion and node update
to a node involving one of the conflicting flights. If not, the current plan CPL(n′) has been ascertained
to be a solution to the scenario.
The cost of the overall plan is then computed and compared to the current upper bound. If it is
lower then the current upper bound, then a new lower-cost plan has been found, and hence the upper
bound is updated, as well as the structure containing the current optimal plan.
If node n contains no conflicts and is not a terminal node, then its successor n′ is created and
placed on top of NodesStack, and the algorithm proceeds to the next iteration, where it will pick
recently created node n′ to analyze.
The loop continues until every node has been deleted from the stack of nodes. It outputs CPLopt,
corresponding to the plan that was last identified as the low cost plan.
3.4.3.B Sub-routines
Algorithms 2 and 3 contain the two sub-routines responsible for creating nodes in the implemented
program. Sub-routine Create First Node() takes the flight plans contained in the Scenario inputed to
the scenario and creates the first node to be placed on the stack. It is called just once, before entering
the algorithm loop. Sub-routine Create New Node(), on the other hand, creates a new node n′ as a
successor of a pre-existing node n.
51
Algorithm: Create First Node()input : Scenariooutput: First node n
for each FPLk in Scenario doAdd tentry to ETA(n)Add first element of Route to NextWP(n)Add initial conditions to FlightData(n)
end
t(n)← min(ETA(n))Aircraft(n)← argmin(ETA(n))CPL(n)← empty
n← Aircraft(n),ETA(n),NextWP(n),t(n),CPL(n), FlightData(n)
Return n
Algorithm 2: Sub-routine that creates first node of the stack
Algorithm: Create New Node()input : ETA(n′),CPL(n′),CPL(n′),FlightData(n′)output: New node n′
Aircraft(n)← argmin(ETA(n′))
n′ ← Aircraft(n′),ETA(n′),NextWP(n′),t(n′),CPL(n′),FlightData(n)
Return n′
Algorithm 3: Sub-routine that creates a new node n′, a successor of n
Algorithm: Backjump()input : NodesStack,ConflictReport
n← Pick topmost element from NodesStack
A← First conflicting aircraft from ConflictReportB ← Second conflicting aircraft from ConflictReport
while Aircraft(n) 6= A and Aircraft(n) 6= B do
Delete n from NodesStackn← Pick topmost element from NodesStack
end
Algorithm 4: Sub-routine that executes backjump following the detection of a conflict
52
Algorithm: Conflict Detection()input : FlightData(n′),t(n),t(n′)output: ConflictReport
ConflictReport ← empty
for t← t(n) to t(n′) do
for each flight A in Scenario do
for each flight B in Scenario do
Check for loss of separation between A and B at time t
if A and B are not separated then
ConflictReport ← (A,B)
Return ConflictReport
endend
endend
Return ConflictReport
Algorithm 5: Sub-routine executing deterministic conflict detection
Algorithm: Robustness Test()input : Scenario,CPL(n′)output: ConflictReport
ConflictReport ← empty
ParticleTrajectories← Predict trajectories for every flight in Scenario, with Np particles per flight
for t← tcurrent to tend do
for each flight A in list of flights do
for each flight B in list of flights do
ConflictCount ← 0
pC(A,B, t)← Compute conflict probability between A and B at time t
if pC(A,B, t) > pthr then
ConflictReport ← (A,B)Return ConflictReport
endend
endend
Return ConflictReport
Algorithm 6: Sub-routine executing robustness test
53
Algorithm: Branch()input : Node n,Scenario
FLcurrent ← Current flight level for Aircraft(n)
FLmin ← Minimum flight level for following route legFLmax ← Maximum flight level for following route leg
for FL← FLmin to FLmax do
i← instruction that takes Aircraft(n) from FLcurrent to FLAdd i to Unexpanded(n)
f(n′)← Compute cost of successor n′ originated by instruction iAdd f(n′) to fun(n)
end
Expanded(n)← emptyfexp(n)← empty
Add Unexpanded(n),Expanded(n),fun(n),fexp(n) to n
Algorithm 7: Sub-routine that executes branch on node n
Algorithm: Update Node()input : Node n,instruction i
Delete instruction i from Unexpanded(n)Add i to Expanded(n)
Delete cost f(n′) of the successor originated by instruction i from fun(n)Add cost f(n′) of the successor originated by instruction i to fexp(n)
Algorithm 8: Sub-routine that updates node n after branch has been expanded
Algorithm: Predict Trajectory()input : Node n,current plan CPL(n′),FlightData(n)output: Trajectory,ETA(n′),NextWP(n′),t(n′)
t← t(n)
Trajectory ← Read initial conditions from FlightData(n)
while Aircraft(n) does not reach next waypoint doTrajectory ← Propagate trajectory obeying CPL(n′)t+ +
end
ETA(n′)← Add t to ETA(n)NextWP(n′)← Increment next waypoint of Aircraft(n) in NextWP(n′)t(n′) = min(ETA(n′))
Return Trajectory,ETA(n′),NextWP(n′),t(n′)
Algorithm 9: Sub-routine that predicts the trajectory of Aircraft(n) according to instruction i
54
Sub-routine Backjump(), shown in algorithm 4, takes as input the current stack of nodes and a
ConflictReport containing a pair of conflicting aircraft A and B and deletes nodes from the top of the
stack until it finds one referring to A or B.
Algorithms 5 and 6 contain the two sub-routines responsible for performing conflict detection.
Conflict Detection() performs deterministic conflict detection on the trajectories contained in Flight-
Data(n′) between t(n) and t(n′). Robustness Test() calculates the trajectories for every flight in
Scenario, with Np particles per flight, and executes probabilistic conflict detection. Both sub-routines
output a ConflictReport, which contains a pair of conflicting aircraft, or is empty if no conflict was
found.
The Branch() sub-routine is shown in algorithm 7. It receives a newly created node n and the
program Scenario. It computes the list of instructions that may executed at node n and their corre-
sponding costs and places the information inside the structure of node n.
Sub-routine Update Node() is shown in algorithm 8. It takes node n and instruction i, which was
recently chosen to expand. In order to store in the node structure the information that instruction i has
been expanded, i is moved from the unexpanded to the expanded list of instructions. This process is
shown in figure 3.15.
Sub-routine Predict Trajectory() is laid out in algorithm 9. It receives as input the current node n,
the current plan and the trajectories calculated so far. It calculates the Trajectory of Aircraft(n) until
it reaches its next waypoint, according to the current plan, returning it as an output. This sub-routine
also outputs the update values for the estimated time of arrival (ETA(n′)), next waypoint (NextWP(n′))
and node time (t(n′)) that will be eventually used to create a successor node n′.
55
3.5 Interactive Multi-Criteria Decision Making
3.5.1 Motivation and definitions
As mentioned in section 3.3, the choice of a two criteria cost function for the implementation of
the branch-and-bound algorithm deters the use of conventional optimization techniques for cases in
which a single criteria is to be minimized. When two or more criteria are included in the cost function,
a multi-criteria (or multi-objective) decision making problem must be solved by the algorithm.
In multi-criteria problems, the concept of optimality of a certain solution is replaced by those of
efficiency and Pareto optimality. In general, there is no optimal solution for a given problem, since
a solution may minimize one of the cost function objectives but not the other. Instead, the goal of a
multi-criteria problem is to calculate the set of solutions that are Pareto optimal (also called efficient).
This set of solutions may be called Pareto front or efficient set.
Assuming p objective functions have to be minimized, a vector f(x) = f1(x), f2(x), . . . , fp(z) may
be defined, where fi(x) represents the ith objective function, and x is a decision (in our case, a global
plan that solves the scenario). Then, a solution xe is efficient if there is no solution xj that verifies
fi(xj) ≤ fi(xe) for all i, with a strict inequality fi(xj) < fi(xe) for at least one objective i. If a solution
is efficient, it is said to be non-dominated. Otherwise, a solution is inefficient, or dominated.
The concept of dominance is illustrated for the case in which p = 2 (also known as bi-objective
case) in figure 3.16. In graphs as the one in the figure, the axes correspond to the objectives to
be minimized and a point in the graph is said to be part of the objectives space. Solution Seff is
efficient or non-dominated, assuming there are no solutions in the filled area, i.e. assuming there
is no solution with a lower cost than Seff in both objectives. Solution Sdom, on the other hand, is
dominated by solution Seff , since f1,eff < f1,dom and f2,eff < f2,dom, and therefore does not belong
to the Pareto set.
3.5.2 Approach selection
Several approaches may be followed to find the efficient set for a given multi-criteria decision
making problem. These approaches may be inserted in one of three categories, depending on the
stage of the algorithm at which the Decision Maker (DM) is involved:
• A priori methods: the DM expresses his preferences before the optimization process begins,
by setting goals for the objective functions, or by explicitly defining the weights. These methods
have the advantage of avoiding the calculation of the entire efficient set of a given problem,
and being directed toward the preferred solution from the start. However, they are not easy to
implement in practice, since it is very difficult for a DM to quantify his preferences beforehand,
without any previous information about the solution set.
• Interactive methods: the algorithm alternates phases of calculation with phases of interac-
tion with the DM. The DM participates in the optimization process and drives the search by
responding to the algorithm’s queries. This may allow the convergence to the preferred solution
56
No solutions Non-dominatedsolution
Dominated by Seff
f1,eff
f2,eff f2
f1
Seff
Sdom
f2,dom
f1,dom
Figure 3.16: Pareto dominance illustration
to happen in few iterations without the calculation of large portions of the Pareto set that would
never be preferred by the DM. The main drawback of interactive methods is that they require the
DM to state his preferences in relation to what he knows of the Pareto set so far, and without a
broad view of it, possibly settling for solutions that are local bests, and far from existing global
bests.
• A posteriori methods: the algorithm calculates the whole Pareto set (or a large representation
of it) before receiving any input from the DM. This allows the DM to see ’the whole picture’ when
selecting the preferred solution and to not spend any of its time assisting the algorithm during
the search phase. The disadvantage of this method is that, for most problems with a large
solution set, the calculation of all the efficient solutions requires a high computational effort.
Taking into account the advantages and drawbacks laid out above for the three categories of
algorithms, the choice was to implement an interactive method in this work. This option avoids the
undesirable calculation of the whole Pareto set (which might be cumbersome for high traffic scenarios)
and allows the DM to express his preferences having some knowledge of the efficient solutions.
Another merit of this solution is that it guarantees the implemented algorithm is able to find all Pareto
optimal solutions, including the non-convex ones.
3.5.3 Interactive algorithm
3.5.3.A Pseudo code
The implemented interactive MCDM algorithm is based on the work presented by Marcotte and
Soland in [27]. Algorithm 10 presents the pseudo code for the interactive algorithm.
57
Algorithm: MCDM()input : Scenario,λNλD
Nmax ←∞Dmax ←∞
ParetoFront ← empty
while ATCO requests the calculation of more plans do
CPLopt ← Optimization(Scenario,λNλD , Nmax, Dmax)
if CPLopt is not empty then
Add CPLopt to ParetoFront
end
Display ParetoFront to ATCO
Receive input action from ATCO
if ATCO accepts one of the proposed plans then
Exit
else
Nmax,Dmax ← Receive restrictions from ATCO
end
if ATCO rejects all plans then
Exit
endend
Algorithm 10: Interactive decision making algorithm
58
It receives as input a Scenario and a weight ratio λNλD
. It starts by initializing the criteria restrictions
Nmax and Dmax as infinite (since no restrictions exist at this point) and a structure ParetoFront, which
will be used to store the list of Pareto efficient solutions, as empty.
The algorithm then enters a loop. It proceeds by calling the function Optimization(), corresponding
to the combinatorial optimization algorithm described in 3.4. This optimization will return the optimal
plan that minimizes the cost function with the specified weight ratio λNλD
, obeying restrictionsN < Nmax
and D < Dmax. If this plan is not empty (i.e. if there is a solution to the problem that respects the
restrictions Nmax and Dmax), it is added to ParetoFront.
The plans contained in ParetoFront are then displayed to the ATCO. Several informations may be
provided: altitude profiles for every flight in the scenario, list of instructions for each plan, difference
between plans, total deviation D for each plan, total number of instructions N for each plan. The
ATCO analyzes the provided information and decides between two actions to take: accept one of the
proposed plans or request the calculation of more plans.
If the ATCO does accept one of the plans contained in ParetoFront, the search has ended, and the
algorithm exits. If, on the other hand, the ATCO decides to request the calculation of more plans, the
algorithm asks the controller to specify which restrictions should apply in the next optimization cycle.
The preference of the ATCO is stored in Nmax and Dmax, and the algorithm initiates the next loop
iteration, where it will use the provided restrictions to calculate a new Pareto optimal plan.
If the algorithm verifies that all Pareto optimal plans have already been calculated, it informs the
controller that no more plans will be calculated. This algorithm terminates when the controller accepts
one of the plans to implement or rejects all suggested plans.
An important detail should be emphasized: the weight ratio λNλD
used in this algorithm does not
affect the end result in what concerns the calculated solutions. The same Pareto front is found by
the algorithm regardless of the value assigned to λNλD
. However, this ratio may affect the order in
which the efficient solutions are found. This may be critical for large scenarios, in which the controller
may accept one of the already calculated solutions before visualizing a representative portion of the
Pareto front. This drawback was not studied in this thesis, and thus the development of methods of
calculating ideal ratios λNλD
(possibly by receiving a priori preferences from the decision maker, or by
empirical observation) to be used in the algorithm is left as future work.
3.5.3.B Example
We suppose the algorithm receives a Scenario and some weight ratio λNλD
, and runs combinatorial
optimization with Nmax = Dmax = ∞. Assuming feasible solutions exist for this specific scenario, a
particular solution is calculated by the algorithm that is optimal for λNλD . This solution – denoted S1 and
shown in figure 3.17(a) – is Pareto optimal, and is therefore the first found element of ParetoFront.
The calculation of a first efficient solution prompts the drawing of two regions in the objectives
space graph (figure 3.17(b)). The red filled region – labeled Pruned solutions – contains all the
solutions nodes that are dominated by S1 (D1 < D and N1 < N ), hence solutions inside this region
may not belong to the Pareto set. The gray filled region – denoted No solutions – is guaranteed to
59
contain no solutions to the scenario, since a solution in this region would dominate S1 (D < D1 and
N < N1) and would have been returned by Optimization() instead of S1. Therefore, any other existing
efficient solutions in this scenario must lie outside the previously described regions, and must outbest
S1 at one (and only one) of the objectives. The remainder of the Pareto set may lie either inside region
I (to the left and above S1) or inside region II (to the right and below S1).
Solution S1 is added to ParetoFront, which is then displayed to the ATCO. The controller is asked
to decide whether he accepts the proposed plan or he wants the algorithm to calculate other plans.
If the controller decides to ask for further suggestions, it must be defined which part of the objectives
space to explore next. The decision is taken by querying the DM. The algorithm presents the situation
shown in figure 3.17(b) to the DM, and requests him to choose between two options:
i Search solutions inside region I. This choice corresponds to including a new restriction to the
number of instructions, namely Nmax = N1. Any Pareto solution verifying N < N1 will penalize
deviation D and will verify D > D1.
ii Search solutions inside region II. This choice corresponds to including a new restriction to the
deviation, namely Dmax = D1. Any Pareto solution verifying D < D1 will penalize the number of
instructions N and will verify N > N1.
The DM is presented with this option, along with the plan corresponding to solution S1, and decides
which region to explore next. This decision may depend, for example, on its present workload and
on the workload brought by the suggested solution. We assume the ATCO decides to explore region
I, i.e. decides to search for solutions with fewer instructions than the ones presented in S1. The
algorithm proceeds to set Nmax = N1, maintaining Dmax =∞, and moves to the next iteration.
In the following iteration, the algorithm runs the Optimization() function with the added restriction
Nmax = N1, and finds a second Pareto optimal solution, denoted S2. At this point, the situation is as
shown in figure 3.17(c).
Solution S2 is then added to ParetoFront and both S1 and S2 are displayed to the controller.
The controller again decides to instruct the algorithm to calculate further solutions. This time, the
presented options to define the optimization restrictions are:
i Search solutions inside region I. This choice corresponds to including Nmax = N2 as restriction.
ii Search solutions inside region II. This choice corresponds to including Dmax = D2 and Nmax =
N1 as restrictions.
iii Search solutions inside region III. This choice corresponds to including Dmax = D1 as a restric-
tion.
We suppose the DM opts to explore region II. The algorithm initiates a new iteration and executes
the corresponding optimization with Dmax = D2 and Nmax = N1. It finds a third solution, denoted
S3, as shown in figure 3.17(d). This solution is added to ParetoFront and presented to the controller,
together with S1 and S2. We assume the ATCO accepts solution S3 to implement, which prompts the
algorithm to exit.
60
3.5.3.C Non-convex solution calculation
Solution S3 is an example of a special case of solutions, and is shown in figure 3.18.
To explain what distinguishes S3 from both S1 and S2, we start by providing a graphic illustration of
the way in which a fixed-weight search works. Fixing the cost function weight coefficients (equivalent
to selecting a fixed ratio (λNλD )0) corresponds to defining a line with a specified slope m. This line is
denoted r in figure 3.18(a), and its slope is given by:
m = −(λNλD
)0 (3.24)
i.e. the angle of inclination between line r and the horizontal axis is tan−1(m) = tan−1(−(λNλD )0).
Any line with slope equal to m (from the family of lines parallel to r) contains the set of points in the
objectives space (all the pairs (N,D)) that share the same total cost f , for the specific weight ratio.
Three lines of this family may be drawn in order to contain solutions S1, S2 and S3, representing total
costs f1, f2 and f3, as shown in figure 3.18(b). The total cost f associated with each line increases
perpendicularly to line r in the direction of increasing N and D. Therefore, for the particular weight
ratio being used, the costs for each solution may be ordered as:
f2 < f1 < f3 (3.25)
which means that solution S2 is the one with the lower cost. Furthermore, assuming no efficient
solutions existed in this scenario besides S1, S2 and S3, S2 would be the optimal solution for the
single-criteria problem created by setting weight ratio (λNλD )0.
We suppose now that the weight ratio (and hence slope m) is made to vary, as shown in figure
3.18(c). By gradually decreasing λNλD
(i.e. by gradually decreasing the module of slope m), several
lines may be obtained. As |m| decreases, slopes from m1 to m5 are obtained. For each of these
slopes, solution S2 has the lower total cost f , hence being optimal. For slope m6, however, S1
becomes the solution with the lower cost, and so it continues to be if the slope module is further
decreased, for slopes between m6 and m10.
This indicates the existence of a region where solutions are efficient (not dominated by either S1
or S2), but cannot be found by just varying the fixed weight ratio λNλD
. This is the non-convex region
indicated in figure 3.18(c), to which solution S3 belongs. Although solution S3 is efficient, it is not the
optimal solution for any weight ratio, and may only be obtained by setting restrictions on the objectives,
as is made in this work’s algorithm. This capacity to find non-convex solutions is an advantage of the
chosen approach, overcoming a flaw of the strategy that consists of simply varying the weights and
enumerating the Pareto efficient solutions, known as weighted sum method.
61
S1D1
N1
D
N
(a) First found solution - S1
I
II
S1D1
N1
No solutions
Pruned solutions
N < N1
D < D1
D
N
(b) First decision to be taken by the ATCO
N < N2
D < D2N < N1
I
II
IIID < D1
D
N
S1D1
N1
S2
N2
D2
(c) Second found solution - S2
D
N
S1D1
N1
S2
N2
D2 S3
D3
N3
(d) Third found solution - S3
Figure 3.17: Pareto optimal set calculation
62
S2
S3
S1
r
D
N
(a) Fixed weight search
D
N
S2 increasing
cost
f2f1f3
r
S3
S1
(b) Total cost f calculation
D
N
Non-convex region
S2
S3
S1
m1m2
m3
m4
m5
m6m7m8
m9
m10
(c) Solution lying in a non-convex region
Figure 3.18: Solution in a non-convex region
63
4Simulation and Results
The present chapter is concerned with the simulations conducted to test the developed algorithm
and the most relevant obtained results. It starts by presenting, in section 4.1, the parameters needed
to establish the simulation environment (airspace, time frame, separation criteria) and to generate
randomized traffic scenarios with variable traffic density. The algorithm performance for varying levels
of scenario complexity is analyzed in section 4.2. In section 4.3, tests are ran to ascertain the benefits
and drawbacks of requiring optimality for the search algorithm.
4.1 Simulation framework
4.1.1 Simulation parameters
To define the simulation framework used to test the algorithm, the following elements were used:
• Airspace
As mentioned before, the controlled airspace used in this work corresponds to Santa Maria FIR,
as defined in the Portugal Aeronautical Information Publication (AIP), above flight level FL290
(29000 ft). As a simplification, the existence of the Santa Maria radar is ignored, hence every
aircraft inside Santa Maria FIR is assumed to be outside radar coverage. Since this work is
focused on the cruise phase of flights, at upper airspace, Santa Maria terminal area (TMA) is
also neglected.
• Time window
The time window for each simulation was set at tsim = 4 hours. Hence, assuming current time
(the real time being observed by the controller) to be denoted tactual, the simulation ends at
some end time tend = tactual + tsim. Although the algorithm does not place any instructions nor
64
does it execute conflict detection further than tend, it may calculate predicted costs beyond tend,
when calculating cost h for some node.
• Separation criteria
The chosen separation criteria were SH = 50 nmi for horizontal separation and SV = 1000 ft for
vertical separation.
4.1.2 Traffic generation
In order to test the algorithm with a high variety of traffic scenarios, it became necessary to develop
a routine to generate randomized flights. This routine ought to produce flight plans with feasible and
reasonable horizontal routes – replicating real flights – and with randomized airspeed, altitude profile
and time of entry in the controlled FIR.
The traffic generation routine picks horizontal routes (sequences of fixes) from a nominal flight
plan pool, with 23 flights. These 23 nominal flight plans all contain commercial routes used regularly
by airlines, and were selected in order to obtain a representative set of the main traffic directions
and flows found regularly through Santa Maria FIR, from two main online sources: FlightAware1 and
Real World Flightplan Database 2. This ensures the scenarios generated and inputed in the algorithm
present a high variety of traffic patterns and geometries.
Each nominal flight plan contains:
• Route: fixed sequence of fixes throughout Santa Maria FIR
• TASnom: nominal value for the aircraft’s true airspeed
• FLnom: nominal altitude profile
• fflight: flight’s frequency (High (H), Medium (M) or Low (L))
Flight frequency was introduced so that the traffic generation routine selects some common flights
more frequently than others that occur more rarely in Santa Maria FIR. The occurrence probability for
flights with H, M and L flight frequencies are denoted respectively pH , pM and pL, and the relation
between these probabilities was set at pH = 2pM = 3pL.
The traffic generation routine receives as input the desired number of flights (NF ) for a certain
scenario. It sequentially selects NF flights from the flight plan pool, picking the flights one at a time.
Each pick is independent, hence the same flight may be selected more than once to form the scenario.
After picking the nominal flight plans, the traffic generator calculates the randomized components
of each scenario flight plan:
• True airspeed: true airspeed is generated assuming a Gaussian distribution, with TASnom as
the expected value and a standard deviation σtas.
TAS ∼ N (TASnom, σ2tas) (4.1)
1http://www.flightaware.com2http://www.edi-gla.co.uk/fpl/
65
• Altitude profile: altitude profile FLprofile is calculated by applying a certain offset FLoff to the
nominal altitude profile FLnom. This offset is normally distributed (FLoff ∼ N (0, σ2fl)) and is
always rounded to the nearest multiple of ten, so that it may be summed (or subtracted) to each
element of the FLnom vector to obtain a new altitude profile.
FLprofile = FLnom + FLoff (4.2)
• Entry time: the flight allocation process is represented in figure 4.1. Entry time (tentry) for
each flight plan is generated by first calculating an estimation of the flight’s total trip time (ttrip)
across the Santa Maria FIR. This is done by assuming the aircraft executes its route with ground
speed equal to its desired true airspeed. As a restriction, a certain percentage of the flight’s trip
time is required to ’fall’ within the simulation time [tactual, tend]. This percentage is defined by
multiplying ttrip by a factor µt < 1. The entry time is then calculated by assuming a uniform
probability distribution inside the entry time window [tmin, tmax].
tentry ∼ U(tmin, tmax) (4.3)
If the calculated entry time is prior to current time (tentry < tactual), the flight is considered to be
inside Santa Maria FIR at the start of the simulation, and the corresponding position report is
calculated. If tentry > tactual, the flight is not yet inside Santa Maria FIR when the simulation is
started, and will enter the airspace at tentry.
Earliest acceptable allocation Latest acceptable allocation
Simulation window
ttrip
tmin tactual tmax tend
ttripttrip ttrip
Entry time window
t
Figure 4.1: Randomized flight allocation
4.2 Algorithm performance
This section presents the results of tests ran with the goal of observing the algorithm’s performance
for varying levels of traffic density.
This objective was attained by measuring running time (the time spent by the algorithm to find
the optimal solution for a given scenario) and memory usage (the maximum instantaneous amount
of memory the algorithm uses during a complete simulation), as the number of flights NF was pro-
gressively increased. For each value of NF, several simulations were ran with different randomly
generated traffic scenarios, and mean values for running time and memory usage were calculated.
The effect of the number of flights on these measurements was then ascertained by repeating the
procedure for varying values of NF and graphically representing the results.
66
4.2.1 Running time
The evolution of running time as a function of the number of flights NF obtained through the tests
described above are plotted in figure 4.2. Figure 4.2(a) exhibits the mean values for each value of NF,
whereas 4.2(b) presents a boxplot representation of the obtained results, obeying the representation
shown in figure 4.3, where IQR denotes the interquartile range.
The obtained graph evidences an approximately exponential growth of running time as the num-
ber of flights increases, starting at about NF = 25. This clearly indicates the complexity of a given
scenario – i.e. the computational effort it requires from the algorithm – grows much faster than the
state-space dimension, which increases linearly with the number of flights NF. The explanation of this
growth is rather intricate and somehow outside the scope of this work (as it deals with the factors
affecting traffic complexity, such as the relative geometry of the aircraft’s trajectories) but it may at-
tributed to the combinatorial effect as more aircraft are added to a scenario, increasing the number of
conflicting aircraft, and forcing the algorithm to explore a much larger percentage of the search tree.
To demonstrate that state-space dimension (represented by a Scenario Number of Nodes, de-
noted SNN) increases linearly with NF, consider a scenario with NF flights. The exact value for the
total number of nodes may be calculated as:
Exact SNN =
NF∏i=1
NRL,i∏k=1
NFL,ik (4.4)
where RLi denotes the number of route legs for flight i and NFL,ik denotes the number of possible
flight levels for route leg k of flight i. As an approximation, it may be assumed that all route legs have
the same number of available flight levels (some constant NFL,0) and that the number of route legs
is the same for every flight in the scenario (a constant denoted NRL,0). In this case, the approximate
value for total number of nodes for the scenario becomes:
Approximate SNN = NF.k (4.5)
where k = (NRL,0.NFL,0) is a constant. This confirms the existence of a linear relation between the
number of flights NF in some scenario and the total number of nodes of the scenario’s search tree
(i.e. its state-space dimension):
SNN ∝ NF (4.6)
This increase in explored search tree area is shown graphically in figure 4.4, by measuring the
variation of the generated nodes (GN) – the total number of nodes generated by branch at a given
simulation – in 4.4(a) and expanded nodes (EN) – the total number of nodes that are actually ex-
panded, with the corresponding trajectory propagation, at a given simulation – in 4.4(b), both as a
function of the number of flights NF. As might be expected, the number of generated and expanded
nodes varies similarly to the running time, indicating that the exponential growth in the time needed
to find the optimal solution is due to an exponential growth in the explored search tree area, as NF
increases.
67
NF5 10 15 20 25 30 35 40
0
t run[s
]
100
200
300
400
500
600
700
(a) Mean values for running time trun as a function of NF
NF5 10 15 20 25 30 35 40
0
200
400
600
800
1000
1200
t run[s
]
(b) Boxplot for running time trun as a function of NF
Figure 4.2: Node generation and expansion as a function of NF
68
Highest observed valuewithin 1.5 IQR of the upper quartile
Third quartile - Q3
Median - Q2
First quartile - Q1
Lowest observed valuewithin 1.5 IQR of the lower quartile
Figure 4.3: Boxplot representation scheme
4.2.2 Memory usage
To complete the performance analysis, the memory used by the algorithm during a simulation was
measured. As was done with running time in 4.2.1, several simulations with random traffic scenarios
were ran for fixed values of NF, and mean values of memory usage were computed. By incrementing
NF, the variation of memory usage was obtained. A graphical representation of the evolution of
memory usage is shown in figure 4.5.
The graph in figure 4.5 clearly shows a liner variation of memory usage with increasing NF. This
was to be expected, as the linear increase in the number of flights increases linearly the memory
occupied by saved trajectory data, which comprises the largest part of stored memory. Since the
algorithm stores just one set of trajectories and one search tree path at a time, no memory incre-
ment occurs as a consequence of a largest percentage of the search tree being explored, hence no
exponential behavior is observed, contrary to the case of running time.
Given that the above analysis showed memory was not a concern regarding this work’s algorithm,
no memory profiling was executed, and memory usage was not examined in greater detail.
4.3 Optimality analysis
The option of introducing optimality as a requirement for this work’s algorithm carries with it a
clear drawback: by not ’settling’ for the first calculated solution (henceforth referred to as the greedy
solution) and continuing the search until no further solutions with lower costs exist - i.e. until the
69
NF5 10 15 20 25 30 35 40
0
5000
10000
15000
GN
(a) Number of generated nodes
NF5 10 15 20 25 30 35 40
0
500
1000
1500
2000
2500
EN
(b) Number of expanded nodes
Figure 4.4: Node generation and expansion as a function of NF
70
5 10 15 20 25 30 35 40 451NF
0
100
200
300
400
500
600
700
800
Max
imum
mem
ory
usag
e[M
B]
Figure 4.5: Maximum memory usage as a function of NF
optimal solution is found - the algorithm dramatically increases its running time.
4.3.1 Optimality gain with traffic increase
In order to easily visualize the additional time spent by the algorithm due to the optimality re-
quirement, the relative difference between tgreedy (the time spent by the algorithm to find the greedy
solution) and trun was calculated and plotted as a function of NF. This relative difference, denoted
trel, is calculated as:
trel =trun − tgreedy
tgreedy(4.7)
This variable is aimed at quantifying how penalizing the optimality requirement is for a certain traffic
volume, in terms of running time. The variation of tgreedy and trel with NF is shown in figure 4.6.
An inspection of the graph in figure 4.6 reveals tgreedy to exhibit an approximately linear increase
with NF. This is due to the fact that the time needed by the algorithm to reach the first leaf node of the
search tree (i.e. to find the greedy solution) is closely related to the depth of the tree, which itself varies
linearly with the number of flights NF, rather than showing a significant correlation with the explored
area, which is controlled by the scenario complexity, as discussed in 4.2.1. As a consequence of this
linear behavior of tgreedy (in conjunction with the already analyzed exponential growth of trun), the
value of trel is an increasing quantity with NF. This leads to the conclusion that the penalization for
choosing an optimal search increases with the increase in traffic volume.
Having analyzed the drawback of seeking an optimal solution to the problem, the focus is now
placed on its benefits. In order to quantify the effect of seeking optimality in the total costs of the
obtained solutions, an optimality gain Gopt is defined. This quantity is calculated as:
Gopt =fgreedy − foptimal
fgreedy× 100[%] (4.8)
The optimality gain Gopt is plotted as a function of NF in figure 4.7.
71
15 20 25 30 35 40
NF
5
10
15
20
25
30
35
40
t greedy[s
]
(a) Time needed to find greedy solution - tgreedy
15 20 25 30 35 40
NF
2
4
6
8
10
t rel
(b) Relative difference trel
Figure 4.6: Additional running time as an effect of optimality
72
15 20 25 30 35 40
0
5
10
15
20
NF
Gopt[%
]
Figure 4.7: Optimality gain Gopt variation with NF
A first analysis of the figure reveals the optimality gain increases with the increase in the number of
flights. This happens due to the occurrence of complex scenarios becoming more common when NF
is increased, which causes the difference between greedy and optimal solutions to be more evident. In
other words, it may be said that the more complex the scenario, the larger the ’room for improvement’
that exists for an optimal algorithm.
Secondly, it is worth observing that the optimality gain Gopt exhibits a high variability, which is itself
a consequence of the high variability of traffic complexity. Even for a high traffic density (high NF ),
many scenarios are created that are not complex enough to cause a considerable difference between
the greedy solution and the optimal solution, which is indicated by the median values. However, there
is a considerable percentage of randomly generated scenarios (and, presumably, of real operational
scenarios) that thoroughly justify the calculation of an optimal solution, and these are the ones that
underline the utility of the developed algorithm.
4.4 Example
Given that the scenarios generated randomly in the last section exhibit a high degree of variation
in complexity (even for the same number of flights NF ) and thus a significant variation on the ’room
for improvement’ that an optimal solution may bring, a specific traffic scenario was handpicked as an
example. An analysis to this example starts by illustrating the effect of λNλD on the calculated optimal
solution, and proceeds to show how a considerable cost reduction may be achieved by searching for
an optimal solution rather than settling for a greedy one.
The chosen scenario is composed of 6 flights. Their FPL’s (and position reports, for those already
inside the FIR at the start of the simulation), along with the graphical representation of their routes,
are shown in figure 4.8. It is assumed that current time (i.e. the real time being observed by the
73
controller) is 0800Z.
Flight A
Flight B
Flight C
Flight D
Flight E
Flight F
20W25W30W35W40W 15W45N
40N
35N
30N
25N
20N
B: A320 N0400F350 40N040W/F360 40N030W 40N020W/F370 ERPES
A: A320 0911Z N0402F350 DETOX/F370 40N020W/F380 35N030W 25N040W
Report: [0721Z,40N040W,FL360]
C: A320 N0413F360 36N040W 37N030W/F370 38N020W GUNTIReport: [0754Z,37N030W,FL370]
D: A320 0847Z N0428F350 HIDRA/F370 40N020W 35N027W/F380 30N040W
E: A320 0829Z N0439F390 KOMUT/F380 38N020W/F370 BEKUN
F: A320 N0401F330 40N040W 40N030W/F360 40N020W/F370 ERPESReport: [0655Z,40N040W,FL330]
DETOX40N020W
35N030W
25N040W
40N040W 40N030WERPES
36N040W
37N030W38N020W
GUNTI
HIDRA
35N027W
30N040W
KOMUT
BEKUN
Figure 4.8: Handpicked scenario
4.4.1 Optimality gain
This scenario was first tested using a criteria weight ratio λNλD
= 1.0. The algorithm is run and starts
by finding a first solution – as mentioned, a greedy solution. The search continues and calculates a
second solution, which ends up being output as the optimal solution, since no further solutions are
found through the remainder of the optimization search.
The altitude profiles for both calculated plans – greedy and optimal – are shown in figure 4.9.
In the figure, the values for deviation D and number of instructions N , as well as the cost f , are
shown for each flight and for each solution. The total cost for each solution, corresponding to the sum
of the costs for each individual flight, is also calculated. This allows the calculation of the optimality
gain Gopt:
Gopt =fgreedy − foptimal
fgreedy× 100[%] =
18735.0− 14270.0
14270.0× 100 = 31.3% (4.9)
which indicates a 31.3% cost reduction from the greedy solution to the optimal solution. An analysis
of the solutions reveals that this is explained by the algorithm resolving the scenario, at first, by
severely penalizing flight A, which flies its whole route below the requested flight level and increases
substantially total cost f , and then finding an alternative solution that forces flights D and F to ’share
the burden’ with flight A, by also deviating from their ideal altitudes. The increase in cost f for flights
D and F is largely compensated by the decrease in cost for flight A, bringing the overall cost down.
74
4.4.2 Effect of λNλD
A second simulation was run on the scenario, this time using a different criteria weight ratio:λNλD
= 300.0. The comparison between the optimal solutions for λNλD
= 1.0 and λNλD
= 300.0 is shown in
figure 4.10.
Since there is no point in comparing the cost f obtained for two simulations with different λNλD
,
the values for total cost f are not shown in this figure, and instead the focus is placed on the values
of total deviation Dtot and total number of instructions Ntot. It is straightforward to observe that by
increasing λNλD
from 1, 0 to 300, 0, the algorithm dramatically increases the weight put on the number
of instructions, and consequently tries to minimize it, reducing Ntot = 7 to Ntot = 3. Given that both
solutions in figure 4.10 are Pareto optimal, they are both non-dominated, and hence the decrease in
Ntot is inevitably accompanied by an increase in Dtot, which is observed to be from 278, 4 to 550, 2.
75
Flight A
Flight B
Flight C
Flight D
Flight E
Flight F
Greedysolution
λN
λD= 1.0
fgreedy = 18735,0
Optimalsolution
foptimal = 14270,0
DA = 317, 2NA = 2
fA = 15960,0
360
370
380
350WP
FL
DETOX 35N030W40N020W 25N040W
360
370
WP
FL
40N030W 40N020W ERPES
DB = 37, 9NB = 0
fB = 1895,0
370
WP
FL
38N020W GUNTI
DC = 0NC = 0fC = 0
360
370
HIDRA
350 WP
FL
40N020W 35N027W 30N040W
380
DD = 0ND = 2
fD = 100,0
370
380
390
KOMUT 38N020W
360WP
FL
BEKUN
DE = 12, 6NE = 1
fE = 680,0
340
350
330 WP
FL
40N030W 40N020W ERPES
360
370
DF = 0NF = 2
fF = 100,0
360
370
380
350WP
FL
DETOX 35N030W40N020W 25N040W
DA = 54, 9NA = 3
fA = 2895,0
360
370
WP
FL
40N030W 40N020W ERPES
DB = 37, 9NB = 0
fB = 1895,0
370
WP
FL
38N020W GUNTIDC = 0NC = 0fC = 0
360
370
HIDRA
350WP
FL
40N020W 35N027W 30N040W
380
DD = 135, 1ND = 2
fD = 6855,0
370
380
390
KOMUT 38N020W
360WP
FL
BEKUN
DE = 12, 6NE = 1
fE = 680,0
340
350
330 WP
FL
40N030W 40N020W ERPES
360
370
DF = 37, 9NF = 1
fF = 1945,0
Figure 4.9: Altitude profiles for greedy and optimal solutions, using λNλD
= 1.0
76
Flight A
Flight B
Flight C
Flight D
Flight E
Flight F
λN
λD= 1.0
Dtot = 278, 4Ntot = 7
λN
λD= 300.0
Dtot = 550, 2Ntot = 3
360
370
380
350WP
FL
DETOX 35N030W40N020W 25N040W
DA = 54, 9
NA = 3
360
370
WP
FL
40N030W 40N020W ERPES
DB = 37, 9
NB = 0
370
WP
FL
38N020W GUNTIDC = 0
NC = 0
360
370
HIDRA
350WP
FL
40N020W 35N027W 30N040W
380
DD = 135, 1
ND = 2
370
380
390
KOMUT 38N020W
360WP
FL
BEKUN
DE = 12, 6
NE = 1
340
350
330 WP
FL
40N030W 40N020W ERPES
360
370
DF = 37, 9
NF = 1
360
370
380
350WP
FL
DETOX 35N030W40N020W 25N040W
DA = 147, 5
NA = 1
360
370
WP
FL
40N030W 40N020W ERPES
DB = 37, 9
NB = 0
370
WP
FL
38N020W GUNTIDC = 0
NC = 0
360
370
HIDRA
350WP
FL
40N020W 35N027W 30N040W
380
DD = 282, 4
ND = 1
370
380
390
KOMUT 38N020W
360WP
FL
BEKUN
DE = 44, 6
NE = 0
340
350
330 WP
FL
40N030W 40N020W ERPES
360
370
DF = 37, 9
NF = 1
Figure 4.10: Altitude profiles for the optimal solution with λNλD
= 1.0 and λNλD
= 300.0 77
5Conclusions
5.1 Conclusions
This thesis is inserted in the ATC automation research field, more specifically in the area of conflict
detection and resolution. Motivated by the increase in air traffic and by the subsequent capacity
overload verified for some airspaces, it follows the approach of developing tools to assist air traffic
controllers and enhance their performance.
A method is presented to execute the tasks of detecting and resolving conflicts automatically, by
predicting the future trajectories of the aircraft present at the controlled airspace and by finding a plan
that simultaneously ensures a safe separation for all flights and minimizes a defined cost function,
which depends on the issued number of instructions and on the deviation from flights from their
requested flight plans. In order to find this optimal solution for a given scenario, a branch-and-bound
algorithm was implemented. This algorithm is both optimal and complete, and the introduction of a
heuristic function allows the pruning of large sections of the search tree, decreasing the computational
effort.
This method was applied to the special case of control in oceanic airspace, where radar cover-
age is inexistent and aircraft positions are not known, except for some mandatory position reports.
Accordingly, some modifications were made to adapt the method to oceanic control: 1) ATC instruc-
tions were restricted to vertical maneuvers 2) instructions are issued exclusively at route waypoints 3)
horizontal separation criteria was increased.
The obtained solutions are robust in what concerns the uncertainty introduced in trajectory pre-
diction by wind. A probabilistic conflict detection routine, based on a Monte Carlo approach, checks
each calculated plan before selecting it as suggestion to the controller.
An interactive approach was chosen to tackle the Multi-Criteria Decision Making problem arising
78
from the fact that a multi-criteria cost function is used. Interaction occurs when the algorithm calcu-
lates a Pareto optimal solution and presents it to the controller, who is may either accept the solution
or instruct the program to calculate a new one, minimizing one of the cost function criteria.
The developed algorithm was subjected to an extensive set of simulations, with varying levels
of traffic density. Traffic generation was randomized to obtain a high variety of traffic patterns and
geometries, hence varying traffic complexity. The algorithm was analyzed regarding its computational
performance, exhibiting an exponential increase in running time as traffic density increases but only a
linear increase in memory usage.
Regarding the cost of the calculated solutions, an improvement was verified between the greedy
solution – used as a benchmark – and the optimal solution for each simulation, especially as traffic
density is increased. Although great variability exists in traffic complexity, and thus in the improvement
brought on by finding the optimal solution instead of settling for the greedy one, the developed tool
excelled and proved its utility for a non-neglectable percentage of the randomly generated traffic
scenarios, by achieving a high reduction in plan cost.
No attempt was made in this work to quantify ATCO workload time reduction and aircraft’s fuel
savings, as such calculations fall somewhat outside the scope of this thesis and would be highly
speculative, but it is safe to affirm that the application of the proposed method in operational context
could be beneficial for both controllers and operators. At the very least, and even if the scenario
complexity does not cause the optimal solution to present a considerable cost reduction relative to
a greedy solution, the tool works as yet another mechanism to ensure the safe separation between
aircraft and as a means to reduce the time spent by controllers separating traffic, freeing them to
perform other tasks.
5.2 Future work
The present section presents suggestions on how to improve and further develop the implemented
program as well as recommendations on future work on the studied field.
5.2.1 Trajectory prediction
Regarding the trajectory prediction method presented in this thesis, the following possible improve-
ments are suggested:
• Introduction of further uncertainty sources: in order to enhance the robustness of calculated
plans, additional disturbances may be introduced when calculating trajectories. We suggest
further study in the human factors field to model pilot compliance to ATC instructions, a factor
that may significantly alter trajectory predictions, especially in terminal areas, where even small
time delays and trajectory deviations are of the utmost importance.
• Improved control scheme: a more precise and complete control scheme might be necessary if
the program is to be adapted to terminal control. Additional control inputs might be introduced
79
and control laws might be altered to generate more realistic trajectories, increasing the reliability
of the calculated plans.
5.2.2 ATC procedures
Considering the flexibility of the developed algorithm, it would be feasible and worthwhile to adapt
it to different applications. A relevant example is the adaptation to conventional ATC in radar-covered
airspace, instead of procedural control in oceanic airspace. This would require several alterations in
the program, of which the following might be mentioned:
• Additional instruction types: if ATC in radar-covered areas is to be implemented, speed changing
maneuvers and horizontal maneuvers must be introduced.
• Instructions issued in intermediate points: in order to introduce conventional control, instruc-
tions may no longer be restricted to route fixes, and intermediate points in the route must be
considered. This complicates the necessary discretization of the problem, and is a considerable
challenge.
• Radar surveillance information: since radar information is made available, the program no longer
relies exclusively on position reports, but rather on radar information. This way, new information
is available to the program on a much more regular basis and an update time must be defined
to define how frequently the program recalculates its solutions.
• Free route: it may be interesting to test the program with aircraft flying direct routes between
entry and exit FIR points, as is done, for example, in Lisboa FIR. This would increase the
geometrical complexity of the scenarios and would serve as an exploratory study to a solution
to be implemented, in the future, in Portuguese airspace,.
5.2.3 Testing
The developed program could be tested more thoroughly with the contribution of a human con-
troller. Two main objectives might be attained:
• Support tool and ATCO solution comparison: by subjecting the support tool and the ATCO to
the same scenarios (working independently of one another), the solutions calculated by the
algorithm might be compared with the strategies employed by the controller. This would provide
insight on the mental model used by controllers and would allow the verification of whether the
automated tools is able to find more efficient plans.
• Tool tested by real ATCO: by subjecting the controller to various scenarios (this time being ad-
vised by the support tool), the usefulness of the tool might be ascertained and advice could be
received on how to improve the algorithm and adapt it to be usable in operational context. Fur-
thermore, one of the proposed objectives for this work – that of reducing a controller’s workload
– might be verified by measuring the workload required from ATCO, for the same scenarios, with
and without the assistance of the algorithm.
80
Bibliography
[1] S. Morton. EUROCONTROL Specification for Medium-Term Conflict Dectection. EUROCON-
TROL, 2010.
[2] B. Bakker. EUROCONTROL Specification for Short Term Conflict Alert. EUROCONTROL, 2007.
[3] H. Nijhuis. Role of the human in the evolution of atm systems - final report. 2000.
[4] B. Kirwan and M. Flynn. Towards a controller-based conflict resolution tool - a literature review.
EUROCONTROL document ASA.01.CORA.2.DEL04-A.LIT, 2002.
[5] J. Kuchar and L. Yang. A review of conflict detection and resolution modeling methods. IEEE
Transactions on Intelligent Transportation Systems, 1:179–189, 2000.
[6] P. Eriksen. Eight-states free route airspace project large scale real-time simulation. north sce-
nario. EEC Report, 363, 2000.
[7] P. Eriksen. Eight-states free route airspace project large scale real-time simulation. south sce-
nario. EEC Report, 365, 2001.
[8] B. Hilburn, H Nijhuis, and M. Joosse. Eight-states free route airspace project. human perfor-
mance measurements. 2001.
[9] N. McFarlane and P. Church. Cost-benefit analysis of free route airspace. 2002.
[10] J. Krozel and M. Peters. Decentralized control techniques for distributed air/ground traffic sepa-
ration. 2000.
[11] J. Krozel et al. System Performance Characteristics of Centralized and Decentralized Air Traffic
Separation Strategies. In 4th ATM R&D Seminar, 2001.
[12] G. Dowek, C. Munoz, and A. Geser. Tactical Conflict Detection and Resolution in a 3-D Airspace.
ICASE Report, 7, 2001.
[13] K. Harper et al. An Agent-Based Approach to Aircraft Conflict Resolution with Constraints. AIAA
Guidance, Navigation, and Control Conference and Exhibit, 2002.
[14] A. Masoud. Using hybrid vector-harmonic potential fields for multi-robot multi-target navigation
in a stationary environment. In International Conference on Robotics and Automation, 1996.
81
[15] N. Durand, J.M. Alliot, and J. Noailles. Automatic aircraft conflict resolution using Genetic Algo-
rithms. In ACM symposium on Applied Computing, pages 289–298, 1996.
[16] S.M. Malaek, A. Alaeddini, and D.S. Gerren. Optimal Maneuvers for Air Conflict Resolution
Based on Efficient GeneticWebs. Aerospace and Electronic Systems, 47, 2011.
[17] Y. Chiang et al. Geometric Algorithms for Conflict Detection/Resolution in Air Traffic Manage-
ment. In 37th IEEE Conference on Decision and Control, pages 1835–1840, 1997.
[18] D. Gianazza, N. Durand, and N. Archambault. Allocating 3D-trajectories to air traffic flows, us-
ing A* and genetic algorithms. In International Conference on Computational Intelligence for
Modelling, Control and Automation, 2004.
[19] D. Gianazza and N. Durand. Assessment of the 3D-separation of Air Traffic Flows. In 6th ATM
R&D Seminar, 2005.
[20] S.I. Kumkov. Conflict Detection and Resolution in Air Traffic Control. RAS Program Mathematical
Theory of Control”, 2008.
[21] J.B. Kuipers. Quaternion and Rotation Sequences. Princeton University Press, 1999.
[22] N. Trawny and S.I. Roumeliotis. Indirect Kalman Filter for 3D Attitude Estimation - A Tutorial for
Quaternion Algebra. Technical Report, 2, 2005.
[23] W. Glover and J. Lygeros. A stochastic hybrid model for air traffic control simulation. In Hybrid
Systems: Computation and Control, 7th International Workshop, 2004.
[24] A. Nuic. User Manual for the Base of Aircraft Data (BADA) revision 3.9. EEC Technical/Scientific
Report, 11, 2011.
[25] ICAO council. Procedures for Air Navigation Services - Air Traffic Management, doc 4444. ICAO,
2007.
[26] L. Yang and J. Kuchar. Prototype conflict alerting system for free flight. In AIAA, Aerospace
Sciences Meeting & Exhibit, 35th, Reno, NV, 1997.
[27] O. Marcotte and R. Soland. An interactive branch-and-bound algorithm for multiple criteria opti-
mization. Management Science, 32, 1986.
82