COURAGE
Key Performance Indicators for
Aircraft Intent Description Models
COURAGE Deliverable D3.2 (30/NOVEMBER/2005)
Submitted to:
EUROCONTROL Headquarters
Attn: Sipke Swierstra and Carlos García-Avelló
The Boeing Company
Research & Technology Europe
Cañada Real de las Merinas, 1-3
Edificio 4 – 4a planta
28042 Madrid, Spain
Research & Technology Europe, Madrid
Cañada Real de las Merinas, 1-3
Building 4 – 4th floor
28042 Madrid, Spain
DOCUMENT NAME
COURAGE Key Performance Indicators for Aircraft
Intent Description Models
DOCUMENT CODE
TBD
CONTENT OWNER
EUROCONTROL HEADQUARTERS
SUBMITTED TO
Mr. Sipke Swierstra
EUROCONTROL HEADQUARTERS, DAS-ATS
Raketstraat, 96
B-1130 Brussels, Belgium
SECURITY LEVEL
N/A
RESPONSIBLE
Miguel A. Vilaplana Ruiz
Boeing Research & Technology Center, Madrid
Telephone +34-91-768-8481
Fax +34-91-768-8408
mailto: [email protected]
DISTRIBUTION LIST
ATTN
CC
Sipke Swierstra (EHQ)
[email protected]
Carlos García-Avelló (EHQ)
[email protected]
Mick Van Gool (EHQ)
[email protected]
Achim Baumann (DFS)
[email protected]
Patrick Calders (DFS)
[email protected]
Bengt Nilsson (Avtech)
[email protected]
DOCUMENT HISTORY
AUTHORS
Miguel A. Vilaplana (BRTE)
Francisco A. Navarro (BRTE)
VERSION
1.0
REVISION
DATE
0.1
13/JUN/2005
Key Performance Indicators for AIDMs
Contents
1 Introduction ............................................................................................................................ 1
2 Preliminary Concepts ............................................................................................................. 1
2.1 Aircraft Intent .................................................................................................................. 1
2.1.1 Classification of Instructions ..................................................................................... 2
2.1.2 Execution Intervals .................................................................................................... 5
2.1.3 Instruction Parameters ............................................................................................... 6
2.2 Operations ........................................................................................................................ 7
2.3 Aircraft Intent Description Model (AID Model) .......................................................... 10
2.3.1 Aircraft Intent Description Language (AID Language) ......................................... 10
2.3.2 Aircraft Intent Description Code (AID Code) ....................................................... 12
3 KPIs for AID Models........................................................................................................... 14
3.1 KPIs for the AID language ............................................................................................ 15
3.1.1 Capability .................................................................................................................. 15
3.1.2 Expressiveness ......................................................................................................... 15
3.1.3 Fidelity ...................................................................................................................... 15
3.1.4 Granularity ............................................................................................................... 16
3.2 KPIs for the encoding/decoding process ..................................................................... 16
3.2.1 Encoding Efficiency ................................................................................................ 16
3.2.2 Encoding Speed ....................................................................................................... 18
3.2.3 Decoding Speed ....................................................................................................... 18
3.2.4 Transmission Speed ................................................................................................. 18
3.2.5 Correctness ............................................................................................................... 19
3.2.6 Scalability .................................................................................................................. 19
3.2.7 Readability ................................................................................................................ 19
Appendix A - References ........................................................................................................ 21
Appendix B - Abbreviations & Acronyms ............................................................................. 23
i
Key Performance Indicators for AIDMs
1 Introduction
In this document, we define a set of Key Performance Indicators (KPIs) for Aircraft Intent
Description models (AID models).
A performance indicator can be defined as a means to gauge or characterize a certain aspect of
the performance of a system. KPIs are those performance indicators that are considered
most meaningful for the assessment of the system’s performance.
The KPIs presented here stem from the domain analysis of trajectory-based applications
documented in [1]. The metamodeling approach adopted to carry out such analysis allows for
the definition of KPIs based on elements common to all AID models. Thus, the resulting
KPIs are applicable across different AID models, thereby facilitating their comparison.
In principle, two types of KPIs can be defined: quantitative and qualitative. KPIs of the
former type define a metric for a certain performance attribute. Such a metric provides a
standard means of measuring that performance attribute, thus allowing its quantitative
evaluation. On the other hand, KPIs of the latter type refer to performance attributes that
are not directly measurable and, consequently, they do not define a metric. Qualitative KPIs
serve to characterize an AID model with respect to performance aspects that are not
quantifiable.
This document is structured as follows. First, several concepts related to aircraft intent in
the domain of trajectory-based applications are introduced. Then, a series of KPIs for AID
models are defined.
2 Preliminary Concepts
2.1 Aircraft Intent
We define aircraft intent as the structured set of instructions that are provided as input to a
Trajectory Engine (TE)1 in order to specify how the aircraft is to be operated during the
time interval for which a computed trajectory is required.
In general, instructions capture basic commands and guidance modes at the disposal of the
pilot/FMS to direct the operation of the aircraft. They can be seen as the mini mal
indivisible pieces of information regarding the operation of the aircraft that are meaningful
to the TE. As we shall see, an instruction must have a mathematical definition that is
compatible with the equations of motion employed by the Trajectory Engine (TE).
1 The TE is responsible for carrying out the trajectory computation process, which consists of generating
the trajectory that results from a given aircraft intent. In general, a computed trajectory consists of a series
of discrete states describing the time evolution of different aspects of the aircraft motion. The trajectory
computation process is based on the integration of a set of equations describing the aircraft motion. The TE
relies on a series of resolution strategies and numerical recipes to integrate those equations into a trajectory.
In addition, a set of underlying models are also required to support the integration, such as the aircraft
performance model (APM) and the atmospheric model.
1
Key Performance Indicators for AIDMs
An instance of aircraft intent is given by a set of instructions combined in the appropriate
manner so that the operation of the aircraft is unambiguously defined. Given an instance of
aircraft intent as input, the TE computes a unique aircraft trajectory. In other words, the
result of integrating the equations of motion used by the TE in conjunction with the
mathematical formulation of the instructions contained in the instance of aircraft intent at
hand is a unique aircraft trajectory.
The aircraft intent is formulated by a client trajectory-based application 2, whose purpose is to
obtain a computed trajectory that realizes a certain flight intent. The flight intent, which can
be thought of as a generalization of the concept of flight plan, is a description of the key
operational requirements and constraints that must be fulfilled by the computed trajectory
(e.g. intended route, operator preferences, standard operational procedures, ATC
constraints, etc)3.
In general, the flight intent does not determine the aircraft motion unambiguously and,
consequently, there are in principle many trajectories (possibly infinite) that fulfill a given
instance of flight intent 4. Thus, the flight intent can be seen as a basic blueprint for
trajectory computation in which the details required to compute an individual trajectory are
left unspecified. In contrast, there are no missing details in the aircraft intent, which
unambiguously describes a specific way of operating the aircraft in accordance to the flight
intent. The aircraft intent is formulated in such a way that the resulting computed trajectory
fulfills the requirements and constraints defined by the corresponding flight intent.
2.1.1 Classification of Instructions
We propose to classify the instructions that are relevant for trajectory computation in ATM
according to the mathematical structure of their effect on the aircraft motion.
The methodology followed to define the different types of instructions consist of
identifying and abstracting the key inputs available to the pilot/FMS for operating the
aircraft within the ATM environment and then grouping the instructions obtained
according to their effect on the ensuing aircraft motion.
We use the term trajectory-based application to refer to any ATM software application that relies on computed
aircraft trajectories to carry out its functions. Thus, a trajectory-based application is client to a trajectory
computation service, at the core of which is a TE. A decision support tool (DST), which relies on an
underlying trajectory predictor (TP), is an example of trajectory -based application.
2
In the specific context of trajectory prediction, it is envisaged that the flight -related data required by the
client application (e.g. an advanced DST) to build the flight intent will be contained in an enhanced Flight
Object, access to which will be controlled via System Wide Information Management (SWIM).
3
In other words, an instance of flight intent may give rise to multiple instances of aircraft intent, each of
them resulting in a different computed trajectory that fulfills the original flight intent.
4
2
Key Performance Indicators for AIDMs
The process of abstracting these inputs (control commands, guidance modes, etc) i nto
instructions is based on an analysis of the flight mechanics and flight control principles
underlying trajectory computation in the ATM context. The result is that the instructions
obtained represent basic ways in which the different degrees of freedom of the aircraft
motion can be controlled. Thus, we assume that, in general, an individual instruction
captures one of the commands, guidance modes or control strategies that are employed in
the ATM context to reduce by one the aircraft motion’s degrees of freedom5.
Instructions are defined as atomic inputs to the TE and, therefore, different TEs will
generally accept different sets of instructions. In any case, the instructions accepted by a
TE are always related to the equations of motion upon which that TE relies (the equations
of motion have to be integrated considering the mathematical description of the
instructions). However, even though different TEs rely on different versions of the
equations of motion, they are all based on a common set of physical principles6. In
consequence, we assume that, regardless of the TE, the effects of the instructions on the
aircraft motion can be grouped into a limited set of types, each corresponding to a different
way of controlling one of the aircraft motion’s degrees of freedom.
Below we present a classification of instructions based on the nature of their effect on the
aircraft motion. Thus, we group together those instructions considered to have the same
type of effect on the aircraft motion, i.e. those instructions whose effect can be described
with mathematical expressions of the same form. The generic instructions introduced to
illustrate the classification are named on the basis of the main feature of their effect, i.e. on
their intrinsic purpose in relation to the aircraft motion. In principle, specific instructions
used by actual TEs can be mapped to the generic instructions considered.
We distinguish the following four broad types of instructions on the basis of their effect on
the aircraft motion: constraints, configuration instructions, control instructions and objectives. This
classification attempts to be exhaustive regarding the types of instructions that are
necessary to fully describe the different possible ways of operating an aircraft in the ATM
context, remaining open to the addition of specific instructions within the types considered .
The objective is that any instruction accepted by a TE can be traced back to one of the
groups identified.
Configuration instructions, which are related to the setting of the aircraft’s instantaneous aerodynamic
configuration, are an exception to this, since they affect the aircraft motion but do not reduce its degrees of
freedom. This type of instructions will be discussed below.
5
The differences among the different versions of the equations of motion generally stem from the different
simplifying assumptions made when applying the Flight Mechanics principles to the problem of aircraft
motion in the specific context of application of the TE.
6
3
Key Performance Indicators for AIDMs
2.1.1.1 Constraints
Constraints are instructions that impose a restriction on the aircraft motion. Such
restriction, which fixes one degree of freedom, can be characterized by an algebraic equation
involving one or more attributes of the aircraft motion (state variables).
The following types of constraints have been identified:

Geometric Constraints. In a constraint of this type, a certain geometric attribute of the
aircraft motion 7 is to remain constant during the execution interval. The constraint
equation involves just one attribute of the aircraft motion. Examples of this type of
constraint are hold bearing (magnetic or true), hold ground track, hold altitude (pressure or
geometric) and hold roll angle.

Kinematic Constraints. In a constraint of this type, a certain kinematic attribute of the
aircraft motion 8 is to remain constant during the execution interval. Again, the
constraint equation involves just one attribute of the aircraft motion. An example of
this type of constraint is hold speed, which can refer to one of the following: indicated
airspeed (IAS), true airspeed (TAS), calibrated airspeed (CAS), Mach number, ground
speed, rate of climb (ROC) or rate of descent (ROD).

Advanced Constraints. In this case, the constraint equation can be fairly complex and may
involve more than one aspect of the aircraft motion. Examples of this type of
constraints are thrust corresponding to engine rating, track geometric path (horizontal or
altitude), and follow speed law (speed vs altitude, speed vs. time, speed vs. weight, etc).
2.1.1.2 Configuration Instructions
Configuration instructions capture the different ways of setting the aircraft’s instantaneous
aerodynamic configuration, such as extending flaps or deploying the landing gear. The main
configuration instructions considered are flaps (high-lift devices) extension/retraction and landing
gear up/down. These instructions are inherently open-loop, i.e. the way in which the change of
configuration takes place is independent of the aircraft motion. The TE, with the support
of the underlying aircraft performance model (APM), is responsible for computing how the
aircraft motion depends on the aerodynamic configuration and how the configurations
changes are effected.
Geometric attributes are those related to the position of the aircraft’s center of mass and the aircraft’s
attitude.
7
Kinematic attributes are those related to the velocity and acceleration of the aircraft’s center of mass. In
addition, aspects related to the aircraft’s motion around its center of gravity (angular velocities and
accelerations) are also considered.
8
4
Key Performance Indicators for AIDMs
2.1.1.3 Control Instructions
Control instructions represent the inputs available to maneuver the aircraft (coordinated
control of the aerodynamic surfaces) and manually control the propulsion plant (throttle
and, if applicable, mixture strength and propeller control). In principle, the pilot/FMS have
direct access to such inputs and can dynamically manipulate them. These instructions
provide the level of detail required to compute aircraft trajectories considering transient
dynamic effects, such as roll in/roll out.
The main control instructions considered are: lateral-directional command (roll in/roll out) 9,
longitudinal command (pull up/push down), speed brakes command and throttle command (throttle
up/throttle down/reverse) 10.
2.1.1.4 Objectives
Objectives capture pilot/FMS commands by which the aircraft is requested to reach a
motion state characterized by a certain target value of a geometric or kinematic attribute of
the aircraft motion. These instructions represent basic autopilot/autothrottle target
acquisition modes at the disposal of the pilot/FMS. The TE, with the support of the
underlying and adjacent models, is responsible for computing the response of the aircraft
to an instruction of this type.
The following types of objectives have been identified:

Geometric Objectives, such as acquire target altitude (pressure or geometric), acquire target bearing
(magnetic or true), acquire target ground track angle, acquire target path angle, acquire target pitch
angle and acquire target roll angle.

Kinematic Objectives, such as acquire target speed, which can refer to one of the following:
IAS, TAS, Mach number, ground speed, ROC or ROD.
2.1.2 Execution Intervals
Each instruction has an associated execution interval, which is defined as the time interval
during which the instruction affects the aircraft motion. For example, the algebraic
equation describing the effect of an instruction of the type constraint must be satisfied
during a certain time interval, which is the execution interval of the instruction. An
instruction is said to be active during its corresponding execution interval.
Assuming coordinated turns (a common assumption for the ATM environment) a single instruction
suffices to capture lateral-directional control inputs.
9
To cater for trajectory-based applications dealing with gate-to-gate operations, control instructions may
also include the inputs available to steer and brake while on the ground (landing gear steering and wheel
braking). In the future one may also have to consider specific control instructions for new vehicle classes to
be integrated in ATM airspace, e.g. helicopters, tilt rotors, UAVs, etc.
10
5
Key Performance Indicators for AIDMs
To compute the aircraft motion that results from an instance of aircraft intent, the TE must
consider the effect of each of the instructions in that instance during their corresponding
execution intervals.
The execution interval of an instruction is defined by means of a begin condition and an end
condition, which specify the start and end times of the interval, respectively. Begin and end
conditions may be explicit or implicit.
An explicit condition can be fixed, in which case the time defining the corresponding
interval endpoint is stated directly 11, or floating, in which case the instruction becomes
active/ceases to be active when a certain explicit condition involving state variables is
satisfied (e.g. hold a certain Mach number in climb until a certain altitude has been
reached).
An implicit condition may be linked, in which case the instruction automatically becomes
active/ceases to be active when another instruction respectively ceases to be
active/becomes active (e.g. start holding altitude when a hold Mach number in climb
instruction ceases to be active) or auto, in which case the TE is responsible for determining
the corresponding endpoint (e.g. in a “fly by” turn, the times when the turn starts and ends
are determined by the TE as part of the computation of the aircraft motion).
Figure 1 depicts the above classification of begin and end conditions using UML
conventions.
Begin and End Condition
: specification
Explicit
Fixed
Implicit
Floating
Linked
Auto
Figure 1. Classification of begin and end conditions according to how they are specified
2.1.3 Instruction Parameters
To fully characterize how an instruction affects the aircraft motion, it may be necessary to
specify the value of one or more parameters associated to the instruction. For example, to
fully define an objective it is necessary to specify the value of the target varia ble to be
achieved12.
When the execution interval is specified by giving the start time (fixed begin condition) together with the
length of the interval, the end condition is also considered as fixed.
11
12
In the case of objectives, the target parameter also plays a role in the specification of the end condition.
6
Key Performance Indicators for AIDMs
The parameters associated to instructions can be classified according to the way in which
they are specified. The resulting classification, explained below, is analogous to the one
obtained for begin and termination conditions.
A parameter associated to an instruction may be either explicit or implicit. An explicit
parameter can be fixed, in which case its value is stated directly (e.g. objectives where the
target value is given as part of the instruction, as in acquire a 20º bank angle), or floating, in
which case the value of the parameter depends on the aircraft type/aircraft operator and
must be provided by the corresponding APM/model of user preferences (e.g. objectives
such as acquire user-preferred bank angle or constraints such as hold economy Mach number, where
the Mach number is a parameter that depends on the aircraft type and the aircraft
operator).
An implicit parameter may be linked, in which case the value of the parameter is
automatically inherited from the previous/next instruction (e.g. in a hold altitude
instruction, the altitude to be maintained can be specified as the aircraft altitude at the start
time of the execution interval, i.e. at the time when the instruction becomes active ) or auto,
in which case the TE is responsible for determining the value of the parameter as part of
the trajectory computation process (e.g. if the aircraft is instructed to perform a “fly by”
turn with constant turn radius, the TE has to determine the applicable radius, which is a
parameter associated to an advanced constraint of the type track 2D geometric path).
2.2 Operations
The execution intervals of different instructions may overlap, i.e. more than one instruction
may be active simultaneously 13. Instructions whose associated execution intervals can
overlap are referred to as compatible. The compatibility of two instructions is possible only if
the responses they elicit from the aircraft are simultaneously feasible, e.g. an aircraft cannot
be requested to simultaneously climb and descend.
We now introduce the concept of operation with the purpose of characterizing the aircraft’s
response to simultaneously active compatible instructions. An operation is defined as the
elemental aircraft behavior that results from the simultaneous combination of a set of
compatible instructions that unambiguously determine the aircraft motion during a certain
time interval. This time interval is denoted as the operation interval. The instructions that give
rise to an operation must be simultaneously active during the operation interval and must
result in a unique trajectory segment for that interval 14. The operation interval is given by
For example, during a turn maneuver, the aircraft may be instructed to initiate a speed change at a certain
moment and an altitude change at a different one. These changes do not necessarily need to be completed at
the end of the turn maneuver.
13
Each operation is then associated to a well-posed mathematical formulation of the aircraft motion with
unique solution in the corresponding operation interval (an operation univocally determines the motion it
causes).
14
7
Key Performance Indicators for AIDMs
the intersection of the execution intervals of the instructions that give rise to the
operation15.
Following from the above definition of operation, the instructions contained in a valid
instance of aircraft intent must give rise to a time-ordered sequence of non-overlapping
operations, each with an associated operation interval. Assuming that the appropriate
underlying models are in place and given the adequate initial or boundary conditions, the
TE would calculate the aircraft motion brought about by each of the operations in the
sequence. The concatenation of the trajectory segments obtained is the computed trajectory
resulting from the execution of the aircraft intent 16.
The relationship between instructions and operations outlined above is illustrated in Figure
2, which schematically depicts an example of how a trajectory is computed from a given
instance of aircraft intent. The figure shows a specific combination of instructions whose
computation results in a trajectory that complies with a certain flight intent. The flight
intent provides information on some aspects of the trajectory to be computed, which in
this case is an en-route descent, such as the intended ground track (track angles and coordinates of the waypoint WP0 to be flown by) and the altitude to level-off at the bottom
of descent (4500 ft). The rest of the information required to unambiguously define how to
operate the aircraft to fulfill this flight intent is included in the aircraft intent.
The instructions that make up the aircraft intent in this example have been grouped
according to the aspect of the aircraft motion they affect. Thus, instructions belonging to
the same group affect the same aspect of the aircraft motion and the instructions in a group
are not compatible among themselves, i.e. a given aspect of the aircraft motion cannot be
simultaneously defined by two different instructions. Four groups are considered: speed,
with the instructions defining the airspeed profile, altitude, with the instructions defining the
airspeed profile, thrust, with the instructions defining the thrust profile, lateral, with the
instructions defining the path/maneuver profile and configuration, with the instructions
defining the aircraft’s instantaneous aerodynamic configuration. As it can be observed, 4
The operation interval is given by the intersection of the execution intervals of the instructions that give
rise to the operation. In principle, the execution interval of an instruction may extend across different
operation intervals.
15
To concatenate the trajectory segments that result from consecutive operations, the con ditions obtained at
the end of an operation interval are used as the initial conditions for the following one.
16
8
Key Performance Indicators for AIDMs
AIRCRAFT INTENT
Speed Profile
HM
Altitude Profile
HM
HCAS
HA
HA
ER(IDLE)
Thrust Profile
HF(CLEAN)
Configuration
?
Lateral Profile
OPERATIONS
RI(?)
HT
OP#2
OP#1
FL320
OP#3
OP#4
OP#5
?
?
HTR(?)
OP#6
RO
OP#7
HT
OP#8
OP#9
TOD
Vertical
M .78
280 KCAS
4500 ft
R?
Horizontal
AIRCRAFT TRAJECTORY
TA
M .88
075
110
Time
Legend
Begin and End Conditions
Fixed
Instructions
Speed Profile
Altitude Profile
Floating
?
Auto
Linked
HM: Hold Mach number HCAS: Hold calibrated airspeed (CAS)
HA: Hold altitude
Thrust Profile
ER(IDLE): Thrust given by idle rating
Configuration
HF(CLEAN): Hold flaps retracted (clean configuration)
Lateral Profile
HT: Hold track RI(?): Roll-in (to bank angle auto) RO: Roll-out
HTR(?): Hold track radius (circular arc of radius auto)
Figure 2. Example of the relationship between instructions and operations
instructions are simultaneously active at each instant of time: 1 belonging to the
configuration group, 1 belonging to the lateral group and 2 belonging to the other 3 groups.
Thus, for a given aerodynamic configuration, the aircraft motion has three degrees of
freedom.
9
Key Performance Indicators for AIDMs
The aircraft intent contains 4 parallel sequences of instructions, which are defined by the
linked begin and end conditions. The sequences are as follows:

Hold initial Mach number (fixed begin condition given by the initial time and end
condition linked to a fixed begin condition), then at a given time set rating to idle and
fly with idle rating (fixed begin condition).

Hold initial altitude (fixed begin condition given by the initial time and floating end
condition) until Mach 0.78 is reached, then hold Mach 0.78 (linked begin condition and
floating end condition) until the value of CAS is 280 kt, then hold CAS (linked begin
condition and linked end condition) and, when the altitude reaches 4500 ft start
holding altitude (floating begin condition).

Maintain clean configuration (fixed begin condition given by the initial time).

Hold track 075 to WP0 (fixed begin condition given by the initial time and linked end
condition), then roll in (auto begin condition and linked end condition) to fly by WP0
with constant turn radius (auto begin condition, linked end condition and auto
parameter), then roll out (auto begin condition and linked end condition) to capture
track 110 from WP0 and then hold that track (floating begin condition).
The figure shows the sequence of non-overlapping operations that result from the
combination of the above sequences of instructions.
2.3 Aircraft Intent Description Model (AID Model)
The AID model is the instrument that the trajectory-based application has at its disposal to
convey to the TE how the aircraft must be operated during the time interval for which a
computed trajectory is required 17. An AID model comprises two elements: an aircraft intent
description language (AID language) and an aircraft intent description code (AID code), which are
defined below.
2.3.1 Aircraft Intent Description Language (AID Language)
We define an AID language as a formal language 18 defined over the finite set of instructions
that can be executed by a certain TE. The instructions belonging to that set, which is the
alphabet of the AID language, are said to be executable by the TE in question 19.
An AID model is an instance of the metamodel of the aircraft intent description domain, which is a sub domain within the domain of trajectory-based applications [1].
17
A formal language is a set (finite or infinite) of strings formed by concatenating symbols (the primitives of
the formal language) belonging to a non-empty, finite set denoted as the alphabet. A grammar is a set of rules
according to which the primitives can be concatenated into strings belonging to the language. Thus, a
grammar defines a language and imposes a structure on the strings in that language [3].
18
In this context, we are considering instructions from a conceptual point of view, focusing only on the
nature of their effect on the aircraft motion.
19
10
Key Performance Indicators for AIDMs
An AID language is defined by a grammar, which is a set of rules according to which the
executable instructions (the primitives of the AID language) can be combined into strings in
the AID language (i.e. valid instances of aircraft intent). The grammar of an AID language
contains rules governing how to combine instructions both sequentially (instructions with
contiguous, non-overlapping action intervals) and simultaneously (instructions with
overlapping action intervals, i.e. compatible). For example, consider a grammar including a
set of rules specifying how the instructions describing horizontal maneuvers can be
concatenated (sequential combinations), a set of rules specifying how the instructions
describing the vertical profile can be concatenated (sequential combinations) and a set of
rules specifying how the instructions describing the speed profile can be concatenated
(sequential combinations). In addition to those three sets of rules, the grammar must
include a fourth one governing how to combine simultaneously instructions describing the
horizontal profile, the vertical profile and the speed profile. The latter set of rules is
necessary to ensure that the resulting aircraft intent completely defines the trajectory to be
computed in an unambiguous manner and according to the model of the aircraft motion
upon which the TE relies 20.
The grammatical rules of an AID language ensure that the input to the TE (i.e. the aircraft
intent, which is a string in the AID language and therefore compliant with those rules),
results in a well-posed mathematical formulation of the aircraft motion (a sequence of
operations) that the TE knows how to integrate into a unique computed trajectory.
An AID language is intimately related to a specific TE: the alphabet of the language
contains the instructions that are executable by that TE and the grammatical rules of the
language are such that those instructions (the primitives of the language) can only be
combined in ways that result in operations that are meaningful for that TE. Therefore, each
TE has an associated AID language, which we call the language accepted by that TE. In
principle, a TE can only accept instances of aircraft intent that belong to the language it
accepts.
The AID language accepted by a TE must be known by any trajectory-based application
that is client to that TE in order to carry out the aircraft intent generation process [1], by which
Using the analogy of a programming language, one can distinguish two levels in the grammar of an AID
language: lexical and syntactical. The lexical level governs the definition of the lexemes in the AID language,
which are the combinations of compatible instructions that give rise to operations when their execution
intervals overlap. The lexemes of a programming language are the basic meaningful strings of ASCII
symbols of the language, such as keywords, operators, variable and function names, etc. The set of ASCII
symbols is the alphabet of the programming language, which is analogous to the set of instructions
executable by the TE (the alphabet of the AID language). The syntactical level governs the construction of
correct sentences in the AID language, i.e. valid instances of aircraft intent. A valid instance of aircraft intent
is analogous to a program source code correctly written in the programming language. Thus, the syntactical
level dictates how to concatenate lexemes (i.e. how to combine sequentially instructions) so that the result is
a valid sequence of operations.
20
11
Key Performance Indicators for AIDMs
the application uses the AID language to formulate the aircraft intent corresponding to a
given flight intent. The aircraft intent generation process results in an instance of aircraft
intent that belongs to the AID language and that, consequently, expresses how the aircraft
is to be operated in a way that is consistent with the mathematical model of the aircraft
motion upon which the TE relies. Thus, the aircraft intent generation process may involve
the introduction of instructions that complete the information provided in the flight intent
so that the aircraft intent obtained is formulated without ambiguity 21.
2.3.2 Aircraft Intent Description Code (AID Code)
As it was outlined in [1], the process by which a trajectory-based application passes on
aircraft intent information to the TE in order to compute a trajectory can be viewed as a
communication process in the context of Information Theory ([4], [5], [6]). The application can
then be considered as a source sending information to a recipient (the TE) via a certain
communication channel.
The source (the trajectory-based application) selects the message to be transmitted to the
recipient (the TE) from a certain message ensemble. In our context, a message is an instance of
aircraft intent expressed according to the AID language accepted by the TE and the
message ensemble is the finite set containing all the instances of aircraft intent that can be
expressed using the AID language 22.
Before being transmitted, the message (an instance of aircraft intent expressed in the AID
language) is encoded by means of the aircraft intent encoder. Upon reception, the transmitted
message is decoded by means of the aircraft intent decoder. The decoding process, which takes
place before the aircraft intent is used as input to the trajectory computation process, is
carried out on the basis of an aircraft intent description code (AID code) 23.
The lateral path initialization carried out during the operation of a TP [2] is an example of aircraft intent
generation where instructions (horizontal maneuvers) are added to the aircraft intent formulation in order to
fill information gaps in the flight plan, eliminating any ambiguity in the description of the aircraft operation.
The aircraft intent generation process may rely on a logic to ensure that the information gaps are filled in
according to operational criteria. Such a logic may require information from the underl ying or adjacent
models (for example operator preferences).
21
The message ensemble, which contains all possible meaningful instances of aircraft intent, may be a very
large set but is conceptually finite. As stated in footnote 19, we consider instructions from the point of view of
the nature of their effect on the aircraft motion, disregarding the specific numerical values used to define
parameters and begin and termination conditions. From this point of view, the set of all possible
combinations (of finite length) of executable instructions is finite.
22
A code is a mapping that associates strings in a certain formal language to strings in another formal
language. Codes are usually employed as mechanisms to improve the efficiency of the communication
channel in some sense, e.g. to compress the information transmitted so that the available bandwidth is used
efficiently ([4], [5], [6]).
23
12
Key Performance Indicators for AIDMs
The AID code is a mapping that associates a string in the AID language to a string in
another formal language. The latter language, which is referred to as the language associated to
the AID code, is designed to facilitate the communication process between the application
and the TE24.
The aircraft intent encoder, which implements the AID code, assigns a string in the
language associated to the AID code to a given instance of aircraft intent (expressed in the
AID language). The aircraft intent decoder reverses the decoding process and recovers the
original aircraft intent, which is then input to the TE.
Even though the AID code is intimately related to the AID language, it provides additional
flexibility to shape the communication process between the client application and the TE.
For example, the AID code may be used to speed up the process of requesting the
computation of trajectories of special interest to the application by using a mapping that
associates short codes to the instances of aircraft intent corresponding to those trajectories.
An AID code may define three different types of mapping: one-to-one, composite-to-one and
implicit.
In a one-to-one mapping, a unique string is assigned to an individual instruction. An
encoded aircraft intent involving mappings of this type would contain the strings
corresponding to all the individual instructions in that instance of aircraft intent that are
encoded with a one-to-one mapping.
In a mapping of the type composite-to-one, a single string is assigned to a whole sequence
of instructions. The sequence, which is denoted as a composite, would normally have an
intrinsic (generally operational) meaning. For example, a single string in the language
associated to a certain AID code may be assigned to a sequence of instructions describing
the individual horizontal maneuvers required to perform a “fly by” turn: roll in-hold bank
angle-roll out. In this case, the composite “fly by” turn would contain three instructions.
In a mapping of the type implicit, an instruction is not encoded25 but must be included in
the decoded aircraft intent whenever a certain combination of instructions is decoded.
Upon decoding of the combination of instructions defined in the mapping, the decoder
incorporates a specific additional instruction to the aircraft intent that is to be input to the
TE, even though that instruction has not been explicitly encoded. Configuration
instructions such as flap extension are usually encoded by means of implicit mappings, i.e.
they are declared implicitly through instructions describing the speed and/or altitude
profile. For example, consider a certain decoder that receives a set of encoded instructions
In general, the language on to which the instances of aircraft intent are mapped by the encoding process
will contain strings over the set of ASCII characters.
24
The instruction may have no assigned string in the language associated to the AID cod e or the encoder
may not explicitly include the assigned string in the encoded aircraft intent.
25
13
Key Performance Indicators for AIDMs
describing the aircraft’s intended speed and altitude profiles during an approach. The AID
code in place may impose that a flap extension instruction be added to the decoded aircraft
intent. That instruction would then be passed as input to the TE, which would be
responsible for calculating (with the support of the APM and the operator preferences
model) when the configuration instruction becomes active and how it affects the aircraft
motion.
In principle, an AID code may simultaneously define mappings of the three types discussed
above.
Figure 3 depicts the above classification of the mappings in an AID code using UML
conventions.
AID Code Mapping
One-to-One
Composite-to-One
Implicit
Figure 3. Classification of the mappings in an AID code
3 KPIs for AID Models
We assume that the only aircraft intent-related information that the client trajectory-based
application passes on to the TE is aircraft intent encoded according to the AID code. The
aircraft intent decoder is then able to extract the original aircraft intent, expressed in the
AID language, from that encoded information.
The AID language and the AID code, together with the associated encodingcommunication-decoding process, have been introduced to define a conceptual framework
(at the metamodel level) that highlights the commonalities among AID models and enables
their comparison in a principled manner. The key elements involved in this conceptual
framework (AID language, AID code, aircraft intent encoder, aircraft intent decoder, etc)
may not be explicitly defined in many trajectory-based applications, but can always be
identified through a process of abstraction. Thus, the proposed framework potentially
supports the definition of KPIs that can be applied to any AID model.
In this section, we present a series of KPIs for AID models defined on the basis of the
aforementioned conceptual framework. They are divided into those characterizing the AID
language and those characterizing the encoding/decoding process. In general, the KPIs
proposed are of a qualitative character, since they refer to elements that may only be
recognized within the trajectory-based application at an abstract level. An effort has been
made to find quantitative metrics for some of the KPIs defined.
14
Key Performance Indicators for AIDMs
3.1 KPIs for the AID language
3.1.1 Capability
The capability of an AID language defines its expressive potential on the basis of the aircraft
intent primitives available and the possibilities to combine them by means of the language
grammar. To evaluate an AID language with respect to this qualitative KPI, one has to
identify and classify the main primitives supported by the language as well as the main rules
governing their possible combinations. The knowledge of those primitives, their character
and their possible combinations provides valuable insight into the types of motion that can
be elicited from the aircraft by using the language. Thus, we can say that capability is a KPI
that serves to qualitatively estimate what can be expressed using the language.
The instructions, i.e. the aircraft intent primitives, in the language alphabet are those
executable by the TE that accepts the AID language under consideration. Consequently,
those instructions will be intimately related to the equations of motion used by that TE.
The grammar of the AID language will also be related to those equations. Thus, the
available information about the TE and the equations it employs is very valuable for the
evaluation of the language capability.
3.1.2 Expressiveness
This qualitative KPI characterizes to what extent an aircraft’s behavioral space (i.e. the set of
all possible behaviors that an aircraft may exhibit in the ATM environment) can be
described by aircraft intent formulated according to the AID language under consideration.
In essence, the evaluation of this KPI consists of characterizing the operations that can be
described by means of the AID language in relation to the set of all possible operations 26.
For example, an AID language that only includes instructions related to the vertical motion
is not expressive enough to describe the behavior of a turning aircraft.
3.1.3 Fidelity
This qualitative KPI serves to describe how well “real” aircraft intent can be described using
the AID language. In other words, the fidelity of an AID language characterizes the
“realism” of its primitives and grammar in the sense of how truthful they are to actual basic
modes of operating an aircraft in the ATM environment. For example, a sequence of
instructions expressing a turn as two consecutive hold bearing instructions can be
considered of lower fidelity than a sequence of instructions expressing the same turn as roll
in-hold bank angle-roll out.
In consequence, to properly evaluate this KPI it would be necessary to define the behavioral space in
terms of operations, which is considered out of the scope of this work.
26
15
Key Performance Indicators for AIDMs
3.1.4 Granularity
This qualitative KPI characterizes an AID language on the basis of the level of detail with
which the aircraft intent primitives in its alphabet capture the detailed dynamics of actual
operating strategies in the ATM environment. For example, an AID language with a
primitive that allows expressing individual roll in and roll out maneuvers would have finer
granularity than a language that does not 27.
3.2 KPIs for the encoding/decoding process
3.2.1 Encoding Efficiency
In general, encoding is a means to improve the efficiency of a transmission in some sense.
Usually, efficiency is considered as a function of the amount of information that actually
traverses the communication channel (the average length of the messages that are
transmitted). In our context, we say that an encoding process (defined by a certain AID
code) is more efficient than another if the former results in shorter encoded messages, on
average, than the latter. We consider encoding efficiency as a qualitative KPI and only
provide some guidance as to how to compare, at a conceptual level, the mappings defined
by different AID codes.
The encoding efficiency resulting from a certain AID code can be defined with respect to
two different aspects: the ability to compress the information transmitted, i.e. whether or
not the AID code defines composite-to-one and implicit mappings, and the entropy of the
information source, which in this context is the trajectory-based application requesting the
computation of a trajectory.
Regarding the first aspect, we consider that an AID code that defines composite-to-one
mappings and/or implicit mappings is more efficient than one that only defines one-to-one
mappings. Typically, AID codes defining composite-to-one and/or implicit mappings are
employed by applications that make extensive use of certain aircraft intent patterns and
require the computation of the resulting trajectories as quickly as possible (e.g. a DST that
iterates on descent trajectories to find the solution to a sequencing problem would require
the computation of a large number of similar descent trajectories in the least possible time ).
Such applications need to optimize the use of the communication channel with the TE, and
they generally do so by employing AID codes that minimize the amount of information
employed to convey the instances of aircraft intent that are most frequently used, i.e. that
compress those instances of aircraft intent through composite-to-one and/or implicit
mappings.
In the latter case, roll in/roll out are either not considered part of a turn maneuver or executed
automatically by the TE in response to a certain turn instruction (they cannot be expressed separately of that
turn instruction).
27
16
Key Performance Indicators for AIDMs
Let us know explore the second aspect with respect to which one can evaluate the
efficiency of the encoding process: the concept of entropy of an information source.
Suppose that a source selects messages at random from a discrete, finite message ensemble
where each message has a certain probability of being selected:
M  m 1 , m 2 ,..., m N 
p(m 1 ), p(m 2 ),...p(m N )
(1)
The entropy H of such a source is defined in [6] as follows:
N
H   p(m i )log 2 p(m i )
(2)
i 1
The entropy H reflects the average “unexpectedness” of the messages selected by the
source, i.e. the average uncertainty of the messages that can be transmitted. H is considered
a standard measure of the average amount of information per message. If the probabilities
associated to the messages are similar i.e. if they all have similar chances of being
transmitted, the entropy of the source is high. In this case, the transmission of a message
conveys a large amount of information, as it is difficult to predict a priori which message is
going to be transmitted. Thus, the average amount of information per message transmitted
is large. If, on the other hand, some messages are much more probable than others, then
the entropy is low. In this case, the average amount of information transmitted per message
is small, since the messages most frequently transmitted are those with the highest
associated probability, which were somehow “expected”. As it can be deduced from (2), the
entropy is maximum when all the messages have the same probability of being selected. In
this case, the average amount of information per message transmitted is also maximum.
Let us assume that, prior to transmission, the messages in M are encoded according to a
certain code. Let L be the average length of the resulting encoded messages, which is
defined as the average number of symbols required to encode a message from M in the
language associated to the code. The efficiency E of the encoding process in relation to the
amount of information transmitted is defined as follows:
E
H
H
/ log 2 D 
L
L log 2 D
(3)
where D is the size of the alphabet used to encode the messages i.e. the size of the alphabet
H
of the language associated to the code. The quantity
is the entropy per symbol
L
transmitted28, which is also a measure of the average amount of information conveyed per
symbol transmitted. As it is shown in [6], the maximum average amount of information that
can be conveyed per symbol transmitted using a code based on an alphabet with D symbols
28
The symbols transmitted belong to the alphabet of the language associated to the code.
17
Key Performance Indicators for AIDMs
is given by log 2 D 29. Consequently, the efficiency E is the ratio of the average amount of
information per symbol achieved by the encoding in place to the maximum average amount
of information per symbol that can be achieved with an encoding based on the same
alphabet.
Considering the discussion above, we could in principle study the probability of each
possible instance of aircraft intent being transmitted by a certain trajectory -based operation
considering its context of operation. In other words, we could study how likely it is that an
application requests the computation of each possible instance of aircraft intent given its
context of operation. We could then analyze whether the encoding in place is efficient in
the sense of producing a short average length of encoded strings with respect to the
entropy of the message ensemble, which is the set of all possible instances of aircraft intent
than can be formulated using the AID language in place. For the encoding scheme to be
efficient according to such criterion, the instances of aircraft intent that can be formulated
using the AID language but are unlikely to be used by the application must be assigned
longer encoded words, while the instances of aircraft intent that are extensively used must
be assigned shorter encoded words. For example, consider a DST whose functionality is
based on the computation of descent trajectories. Suppose that the DST uses a TE and
associated AID language that also allows it to compute climb trajectories, which would be
rarely requested in the normal operational context of the application. An efficient encoding
scheme in this case should use less symbols to encode the instances of aircraft intent
describing descents than those describing climbs.
3.2.2 Encoding Speed
This quantitative KPI measures the time taken, on average, to encode a representative
instance of aircraft intent. This KPI depends on the specific implementation of the
encoding.
3.2.3 Decoding Speed
This quantitative KPI measures the time taken, on average, to decode a representative
instance of encoded aircraft intent. This KPI depends on the specific implementation of
the decoding scheme.
3.2.4 Transmission Speed
This quantitative KPI is a measure of the time taken, on average, by a representative
instance of encoded aircraft to get across the communication channel , i.e. to travel from
This maximum amount would be achieved with an encoding that takes full advantage of the probabilities
of the messages in the ensemble, assigning shorter strings to more probable messages, whose transmission
conveys less information, and longer strings to less probable messages, whose transmission conveys more
information.
29
18
Key Performance Indicators for AIDMs
the output of the encoder to the input to the decoder. This time depends on the available
communication bandwidth 30.
3.2.5 Correctness
This qualitative KPI indicates whether a decoder is capable of performing a static validation
[1] of the decoded aircraft intent, i.e. if it is able to check that a decoded piece of aircraft
intent complies with the grammatical rules of the AID language in place 31.
3.2.6 Scalability
This qualitative KPI is related to the susceptibility of the AID code to be extended by
introducing composite-to-one mappings and/or implicit mappings.
3.2.7 Readability
This qualitative KPI refers to the amenability of the encoded aircraft intent to be read by a
human.
In this context, communication bandwidth would depend on the means (middleware, direct data passing,
etc) employed to transmit encoded aircraft intent.
30
31
Static validation is performed prior to trajectory computation.
19
Key Performance Indicators for AIDMs
Appendix A - References
[1]. COURAGE Domain Analysis, Deliverables D2.1 and D3.1, BR&TE, DFS and Avtech.
November 2005. April 2005.
[2]. Common Trajectory Prediction-Related Terminology. FAA/EUROCONTROL Cooperative
R&D Action Plan 16: Common Trajectory Prediction Capability.
[3]. Kelley, D. Automata and Formal Languages: An Introduction. Prentice Hall - Simon
& Schuster International Group 1995.
[4]. Khinchin, A.I. Mathematical Foundations
Publications, Inc., New York 1957.
of
Information
Theory.
Dover
[5]. Shannon, C.E., Weaver, W. The Mathematical Theory of Communication. University
of Illinois Press. Urbana and Chicago Dover 1949, 1998.
[6]. Reza, F. M. An Introduction to Information Theory. Dover Publications, Inc., New
York 1961, 1994.
21
Key Performance Indicators for AIDMs
Appendix B - Abbreviations & Acronyms
AID Aircraft Intent Description
AIDM Aircraft Intent Description Model
APM Aircraft Performance Model
ATM Air Traffic Management
BR&TE Boeing Research and Technology Europe
CAS Calibrated Airspeed
COURAGE Control of UPTs in a Restricted ATM Ground-centered Environment
DST Decision Support Tool
EUROCONTROL European Oraganisation for the Safety of Air Navigation
KPI Key Performance Indicator
SID Standard Instrument Departure
STAR Standard Terminal Arrival Procedure
TAS True Airspeed
TP Trajectory Predictor
23