May 20

NASA/

Traff

(TAS

Jeffrey H

Engility C

013 

/CR–2013

ffic Aw

SAR) 

Henderson 

Corporation

3-218001

ware St

Conce

n, Billerica, M

trategi

ept of O

MA 

ic Airc

Opera

rew R

ations

equests 
NASA STI Program . . . in Profile

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA scientific and technical information (STI) 

program plays a key part in helping NASA maintain 

this important role. 

The NASA STI program operates under the 

auspices of the Agency Chief Information Officer. 

It collects, organizes, provides for archiving, and 

disseminates NASA’s STI. The NASA STI 

program provides access to the NASA Aeronautics 

and Space Database and its public interface, the 

NASA Technical Report Server, thus providing one 

of the largest collections of aeronautical and space 

science STI in the world. Results are published in 

both non-NASA channels and by NASA in the 

NASA STI Report Series, which includes the 

following report types: 

 TECHNICAL PUBLICATION. Reports of 

completed research or a major significant phase 

of research that present the results of NASA 

Programs and include extensive data or 

theoretical analysis. Includes compilations of 

significant scientific and technical data and 

information deemed to be of continuing 

reference value. NASA counterpart of peerreviewed formal professional papers, but 

having less stringent limitations on manuscript 

length and extent of graphic presentations. 

 TECHNICAL MEMORANDUM. Scientific 

and technical findings that are preliminary or of 

specialized interest, e.g., quick release reports, 

working papers, and bibliographies that contain 

minimal annotation. Does not contain extensive 

analysis. 

 CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

 CONFERENCE PUBLICATION. 

Collected papers from scientific and 

technical conferences, symposia, seminars, 

or other meetings sponsored or cosponsored by NASA. 

 SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, 

often concerned with subjects having 

substantial public interest. 

 TECHNICAL TRANSLATION. 

English-language translations of foreign 

scientific and technical material pertinent to 

NASA’s mission. 

Specialized services also include organizing 

and publishing research results, distributing 

specialized research announcements and feeds, 

providing information desk and personal search 

support, and enabling data exchange services. 

For more information about the NASA STI 

program, see the following: 

 Access the NASA STI program home page 

at http://www.sti.nasa.gov

 E-mail your question to help@sti.nasa.gov

 Fax your question to the NASA STI 

Information Desk at 443-757-5803 

 Phone the NASA STI Information Desk at 

443-757-5802 

 Write to: 

 STI Information Desk 

 NASA Center for AeroSpace Information 

 7115 Standard Drive 

 Hanover, MD 21076-1320
National A

Space Adm

Langley R

Hampton, 

May 20

NASA/

Traff

(TAS

Jeffrey H

Engility C

Aeronautics and

ministration 

esearch Center

Virginia 23681

013 

/CR–2013

ffic Aw

SAR) 

Henderson 

Corporation

d 

r 

1-2199 

3-218001

ware St

Conce

n, Billerica, M

trategi

ept of O

MA 

P

u

ic Airc

Opera

Prepared for L

under Contract

crew R

ations

Langley Researc

t NNL12AA06

Reques

ch Center

6C 

sts 
Available from: 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 

443-757-5802 
Preface 

This document is a description of the TASAR Concept of Operations. The document was prepared by Engility 

Corporation, 300 Concord Road, Billerica, MA under Contract No. NNL12AA06C with NASA Langley Research 

Center, Hampton, VA. The NASA Technical Monitor is David J. Wing. 

 
Abstract 

Aircrews submit trajectory change requests to air traffic control (ATC) to better achieve the operator's preferred 

business trajectory. Requests are currently made with limited information and are often denied because the change is 

not compatible with traffic. Also, request opportunities can be overlooked due to lack of automation that advises 

aircrews of trajectory changes that improve flight time, fuel burn, and other objectives. The Traffic Aware Strategic 

Aircrew Requests (TASAR) concept leverages Automatic Dependent Surveillance-Broadcast (ADS-B) surveillance 

information to advise the aircrew of beneficial trajectory changes that are probed for traffic compatibility prior to 

issuing the request to ATC. This document describes the features, benefits, and limitations of TASAR automation 

hosted on an Electronic Flight Bag. TASAR has two modes: (1) auto mode that continuously assesses opportunities 

for improving the performance of the flight and (2) manual mode that probes trajectory changes entered by aircrews 

for conflicts and performance objectives. The roles and procedures of the aircrew and ATC remain unchanged under 

TASAR. 
Table of Contents 

1. Introduction ........................................................................................................................................................... 1

1.1. Scope ................................................................................................................................................................ 1

1.2. Background ...................................................................................................................................................... 1

1.3. Problem Statement ............................................................................................................................................ 1

1.4. Document Overview ......................................................................................................................................... 2

2. Current Operations ................................................................................................................................................ 3

2.1. Aircrew Roles and Responsibilities when Requesting a Trajectory Change .................................................... 3

2.2. Controller Roles and Responsibilities when Responding to an Aircrew Request ............................................ 3

3. Justification and Description of Changes .............................................................................................................. 4

3.1. Capabilities ....................................................................................................................................................... 4

3.2. TASAR Automation Hosting ........................................................................................................................... 5

3.3. Intended Users .................................................................................................................................................. 5

4. TASAR Concept of Operations ............................................................................................................................ 6

4.1. Assumptions and Constraints ........................................................................................................................... 6

4.2. Primary Inputs from Aircrew ........................................................................................................................... 6

4.3. Additional Input Parameters ............................................................................................................................. 8

4.4. Automated Information Gathering ................................................................................................................... 9

4.5. Dispatch Integration ....................................................................................................................................... 10

4.6. Probing for Conflicts and Generating Trajectory Changes ............................................................................. 11

4.7. Displaying Trajectory Change to Aircrew ...................................................................................................... 13

4.8. Aircrew Request Negotiation with Controller ................................................................................................ 14

4.9. Benefits to be Realized ................................................................................................................................... 15

5. Potential Evolution Paths for TASAR ................................................................................................................ 18

5.1. 4DT Negotiation via DataComm .................................................................................................................... 18

5.2. Flight Deck Planning with ANSP Feedback................................................................................................... 18

5.3. Enhanced Flight Plan with Alternative Trajectories and Preferences ............................................................. 18

5.4. Types of Trajectory Constraints ..................................................................................................................... 18

6. Operational Scenarios ......................................................................................................................................... 19

6.1. Sequence for Automated Monitoring for Opportunities (Auto Mode) ........................................................... 19

6.2. Sequence for Pilot Initiated Use with Conflict Probing (Manual Mode) ........................................................ 21

7. Definitions .......................................................................................................................................................... 22

8. References ........................................................................................................................................................... 23

List of Tables and Figures 

Table 3-1 List of Capability Shortfalls .......................................................................................................................... 4

Table 4-2 Trajectory Changes ..................................................................................................................................... 11

Figure 4-1 TASAR Benefit Mechanisms .................................................................................................................... 16

Figure 4-2 Mechanisms for Potential Negative Effects of TASAR ............................................................................ 16
1 

1. Introduction 

The NASA Traffic Aware Strategic Aircrew Requests (TASAR) Concept of Operations (ConOps) offers 

onboard automation for the purpose of advising the pilot of traffic compatible trajectory changes that would be 

beneficial to the flight.1 The TASAR onboard automation is expected to be hosted on a Class II Electronic Flight 

Bag (EFB) and leverages Automatic Dependent Surveillance Broadcast (ADS-B) surveillance information to 

increase the likelihood of Air Traffic Control (ATC) approval of pilot-initiated trajectory change requests, thereby 

increasing the portion of the flight flown on or near a desired business trajectory. All automation and pilot 

procedures are fully dedicated to a single aircraft, which allows tailoring of optimization criteria to the specific 

objectives of each flight and provides for timely responses to changing situations. 

There is no change in separation responsibility under the TASAR concept. ATC has responsibility to separate 

Instrument Flight Rules (IFR) aircraft and maintains authority over the trajectories of all IFR aircraft in controlled 

airspace. IFR pilots are not permitted to make changes to their approved trajectory without first receiving approval 

from ATC. 

1.1. Scope 

This ConOps focuses on a range of capabilities for a near-term TASAR deployment within the current (2013) 

operating environment. The initial TASAR prototype deployment will, at a minimum, advise pilots of beneficial 

trajectory changes and leverage ADS-B surveillance information to increase the likelihood of ATC approval. Other 

capabilities described in this document, such as the potential future TASAR evolution paths in Section 5, 

may not be a part of the initial TASAR prototype deployment. This document also suggests how TASAR could 

evolve beyond a near-term deployment, but the near-term application remains the focus of this document. 

1.2. Background 

Referred to as user requests, trajectory change requests from aircrews may not be achieving their full potential 

to provide user benefits. Strategic traffic information is currently unavailable to most flight crews, so a trajectory 

change request has a reasonable chance of not being approvable by the controller because of resulting conflicts. The 

flight crew has access to tactical traffic information through the Traffic Alert and Collision Avoidance System 

(TCAS), but the time horizon of less than a minute to a few minutes is insufficient to check for conflicts. Also, 

probing for future conflicts to plan trajectory changes does not match the intended purpose of TCAS. Disapproved 

user requests are an operational detriment since they unproductively increase pilot and controller workload, 

contribute to radio frequency congestion, discourage further attempts by the pilot to optimize his flight, and do not 

produce a more desirable trajectory. In addition, conflict-free opportunities for improving the trajectory can remain 

undiscovered by pilots due to the lack of onboard traffic information and automation to compute more optimal 

trajectory changes that could be approved. 

1.3. Problem Statement 

Aircraft operating under IFR must fly trajectories approved by ATC. The approved trajectory often does not 

coincide with the aircraft operator’s preferred business trajectory. Less-desired trajectories can be the result of 

previously assigned non-optimal routes, altitude and/or speed restrictions issued by ATC, and changing conditions 

or priorities during the flight. Some causes of in-flight priority changes are unanticipated weather (e.g., convective 

weather, turbulence, and icing), destination change, the need to make up time as a result of an earlier delay or 

reroute to avoid traffic or weather, the need to delay the arrival due to traffic congestion at the destination, and the 

need to increase altitude as fuel is burned to improve efficiency. As a result, pilots have a need or desire to change 

their trajectory while in flight. Requests for such changes today are often denied because of projected traffic 

conflicts that might result from their use. 
2 

1.4. Document Overview 

This document is divided into the following sections: 

 Section 1 introduces the TASAR concept 

 Section 2 describes the roles and responsibilities of the controller, aircrew, and other actors within current 

operations 

 Section 3 describes shortfalls of current user requests that the TASAR concept addresses as well as a short 

description of procedural changes under TASAR 

 Section 4 provides a detailed description of the TASAR concept focusing on aircrew interaction with the 

onboard automation and the desired functions and behaviors of the onboard automation 

 Section 5 describes potential TASAR future evolution paths 

 Section 6 provides operational scenarios that show the interactions among the onboard automation, aircrew, 

controllers, and other actors 
3 

2. Current Operations 

This section describes the current roles and responsibilities of the aircrew and controller when aircrews send 

requests to controllers. The lists in Sections 2.1 and 2.2 are not comprehensive and are presented for the purpose of 

describing in Section 4 how TASAR aids the aircrew and controller in performing their roles and responsibilities. 

No change in aircrew or controller roles and responsibilities are suggested under the TASAR ConOps. 

2.1. Aircrew Roles and Responsibilities when Requesting a Trajectory Change 

Today, when requesting a trajectory change, the aircrew has the following roles and responsibilities. 

 Role of aircrew is to make trajectory change requests that meet their safety and efficiency objectives. 

 Aircrew has responsibility for safety of flight and will not request a trajectory change that compromises 

safety. For example, the aircrew considers fuel reserves, convective weather, turbulence, and icing. 

 Aircrew has responsibility to verify that the aircraft performance is sufficient to execute the change as 

requested. For example, the aircrew considers aircraft performance ceiling when making an altitude 

request. 

 Aircrew has responsibility to verify that the aircraft equipment is sufficient to execute the requested 

operation, e.g., Reduced Vertical Separation Minima (RVSM). 

 Aircrew has responsibility to generate requests that conform to operator policies and procedures. 

 Aircrew has responsibility to coordinate with dispatcher and company operations as necessary. 

 Aircrew has responsibility to limit requests so that the ATC voice communications frequency remains 

available for safety critical clearances. 

 Aircrew has responsibility to execute approved requests. 

 Aircrew has responsibility to execute or state inability to execute ATC amended requests. 

2.2. Controller Roles and Responsibilities when Responding to an Aircrew Request 

Today, when responding to an aircrew request, a controller has the following roles and responsibilities. 

 Controller will consider and approve aircrew requests when practicable. 

 Controller has responsibility to separate aircraft and will not approve a trajectory change request that 

violates minimum separation requirements. 

 Controller has responsibility to reject aircrew requests that violate their standard operating procedures or do 

not conform to traffic management initiatives that are in place. However, certain restrictions and initiatives 

can be lifted after appropriate inter-sector coordination. 

 Controller has responsibility to issue clearances and respond to aircrew requests in such a way that the 

voice communications frequency remains clear for safety critical clearances. 

 Controller has responsibility to issue an approval, amendment, deferral, or denial in response to a request. 
4 

3. Justification and Description of Changes 

There are no changes to the roles and responsibilities of the aircrew or controller under the TASAR concept. 

The pilot uses current procedures to request the trajectory change, including determining the appropriate time to 

make the request. The pilot is not obligated to make any request including requests provided by TASAR 

automation. All information from TASAR automation is advisory only. No reference to TASAR is required when a 

request to ATC is made since no special consideration is being requested. 

3.1. Capabilities 

The TASAR concept provides additional onboard automation to aircrews with the following two functions that 

support aircrew requests: 

1. Calculating changes from the current trajectory to better meet user objectives such as fuel burn, flight time, 

and ride quality. 

2. Using ADS-B surveillance information to make trajectory change requests more acceptable to the 

controller by excluding those requests with conflicts at a short look-ahead time horizon that would be 

detected using the ADS-B information. 

These two functions address the capability shortfalls listed in Table 3-1. 

Table 3-1 List of Capability Shortfalls 

Capability 

Category Existing Capability Future TASAR Capability Capability Gap 

Aircrew preferred 

trajectory selection 

Post-departure trajectory changes 

depend on either (1) coordination 

with the flight dispatcher to take 

account of changing conditions or 

(2) experience, rules-of-thumb, or 

limited automation (e.g. 

computation of economy cruise 

speed) to make decisions 

independent of the flight 

dispatcher. 

Onboard automation can recompute optimal trajectory in 

response to changing traffic and 

weather conditions as well as be 

responsive to the aircraft state 

and changing priorities of the 

operator and aircrew. 

Lack of automation for 

trajectory optimization on 

the flight deck. 

Aircrew manually enters winds 

into Flight Management System 

(FMS) at waypoints along 

trajectory. 

TASAR onboard automation 

integrates dynamic winds, 

convective weather, and 

temperature information when 

developing trajectory changes 

that improve objectives. This 

functionality does not include 

sending wind information to the 

FMS. 

Dynamic weather (winds, 

convective weather, 

temperature, turbulence) 

information is not 

integrated into onboard 

automation that computes 

trajectories. 

Aircrew estimation 

of trajectory change 

acceptability to the 

controller 

Aircrews use situational 

awareness obtained from voice 

frequencies as well as experience 

to estimate acceptability of a 

trajectory change to the 

controller. 

Onboard trajectory planning 

automation considers ADS-B 

surveillance information in 

recommended trajectory changes.

Lack of automation that 

considers surrounding 

traffic information on the 

flight deck in the selection 

of trajectory change 

requests. 

Aircrew estimates whether 

trajectory change will occur in 

current sector or a downstream 

sector based on experience and 

rules-of-thumb. 

Onboard automation uses 

knowledge of sector boundaries 

to determine if a trajectory 

change begins in the current 

sector or a downstream sector. 

Lack of automation that 

integrates sector boundary 

information into aircrew 

trajectory change request 

decision-making. 
5 

3.2. TASAR Automation Hosting 

The onboard automation is proposed to be hosted on a Class 2 EFB to permit read-only access to data from the 

aircraft’s systems, such as the FMS and flight control interfaces. A Class 2 EFB is physically mounted in the 

cockpit convenient to the pilot and therefore more likely to be used and provide benefit. 

3.3. Intended Users 

TASAR is intended to be used by any FMS-equipped civil flight operation in the continental United States that 

files IFR with a flight planned cruising altitude at or above 10,000 ft Mean Sea Level (MSL). Federal Aviation 

Regulations restrict aircrews to performing only those duties required for the safe operation of the aircraft below 

10,000 ft MSL excluding cruise below 10,000 ft MSL. This rule minimizes distractions to the flight crew during 

critical phases of flight that include taxi, takeoff, and landing. To be consistent across phases of flight, TASAR will 

become active when the aircraft is at or above 10,000 ft MSL and will deactivate after descending below 10,000 ft 

MSL. 

The 10,000 ft MSL floor could be set as a configurable parameter for users planning to cruise below 10,000 ft 

MSL. 
6 

4. TASAR Concept of Operations 

This section describes the aircrew interaction with the TASAR onboard automation and air traffic controllers. 

Section 6 expands on this section by presenting operational scenarios that describe the interactions. This section is 

organized as follows. 

Section 4.1 Assumptions and Constraints 

Section 4.2 Inputs from Aircrew 

Section 4.3 Configurable Parameters 

Section 4.4 Automated Information Gathering 

Section 4.5 Dispatch Integration 

Section 4.6 Probing for Trajectory Changes 

Section 4.7 Displaying Trajectory Change to Aircrew 

Section 4.8 Aircrew Request Negotiation with Controller 

Section 4.9 Benefits to be Realized 

4.1. Assumptions and Constraints 

The Federal Aviation Administration (FAA) has mandated that aircraft be equipped with ADS-B OUT by 2020 

to operate in airspace that currently requires a transponder. If a sufficient percentage of aircraft are not equipped 

prior to the 2020 mandate (or have not enabled their ADS-B OUT systems), then the TASAR automation will still 

be able to offer optimized trajectory changes but will not be as effective in removing the potential for future 

conflicts. It is assumed that enough aircraft will be equipped prior to 2020 to provide sufficient traffic information 

for conflict probing or that sufficient supplemental traffic information is available from Traffic Information Services 

Broadcast (TIS-B) or other data sources. 

The TASAR concept may also be constrained by the broadcast power of the ADS-B OUT antenna for aircraft 

sending ADS-B messages and the sensitivity of the ADS-B IN antenna for aircraft receiving ADS-B messages. The 

air-to-air broadcast and reception range could be as short as 20 nautical miles (nmi) if aircraft equip to the basic 

requirements of the 2020 ADS-B mandate. However, airlines and high-end general aviation operations that operate 

at higher altitudes are expected to equip their aircraft with extended ADS-B equipage to achieve a minimum of 60 

nmi air-to-air range. 

4.2. Primary Inputs from Aircrew 

This section describes primary inputs that the aircrew will have the option of modifying during flight. Section 

4.3 contains additional parameters that will not typically be modified by the aircrew during flight. The aircrew will 

be provided with default settings for all of the inputs included in this section. 

(a) Mode of Operation 

TASAR automation operates in two modes: (1) automated monitoring for opportunities (Auto mode) and (2) 

pilot initiated use (Manual mode). In Auto mode, the TASAR automation performs a continuous assessment of 

opportunities for improving the performance of the flight. In Manual mode, the pilot enters a desired trajectory 

change into the automation interface which is then probed for conflicts and performance objectives. Conflict 

probing for both Auto and Manual modes is intended to be consistent with controller conflict probing described in 

Section 4.6. The TASAR automation indicates if there are conflicts known to the automation in Manual mode and 

computes a conflict-free modification to the desired trajectory change. 
7 

An Auto mode or Manual mode request may be denied by ATC, but ATC could offer a modification that is 

conflict-free and ask the aircrew if the modified trajectory meets the objectives of the aircrew. The TASAR 

automation and the conflict probe used by ATC may have differing knowledge of future four-dimensional (4D) 

trajectories of surrounding traffic that could cause the TASAR automation to consider the trajectory proposed by 

ATC to contain a conflict. In this case, a Manual mode without conflict probing may have utility by evaluating the 

trajectory against the objective function and aircrew constraints (e.g., time constraints, reserve fuel) but not probe 

for conflicts. 

The TASAR automation is in Auto mode by default and switches to Manual mode when requested by the 

aircrew or the automation senses the aircrew has entered a desired trajectory change into the FMS. 

(a) Aircrew Request Complexity 

The frequency of ATC issuance of clearances, the requests by other aircrews that are accepted or denied, the 

type of clearances issued by ATC, and the tone and urgency of the controller’s voice can all give an indication of the 

workload the controller is currently experiencing and the acceptable complexity of an aircrew request. More 

complex requests could be available in low controller workload situations but could be unavailable in higher 

workload situations such as routing aircraft around severe weather. The aircrew could dynamically increase or 

decrease the complexity of the request in order to tailor the request to the situation. 

Complexity would be defined by the number of entities in the request, with the lowest complexity requests 

being a simple “direct to” request or an altitude change. More complex requests would include adding one or more 

“off route” waypoints, as well as combining altitude and lateral (waypoint) requests. When generating a trajectory 

change, the TASAR automation will consider the pilot-selected request complexity as well as all levels below the 

selected request complexity. A default complexity setting will be provided. 

(b) Optimization Objective 

For operations in Auto mode, the aircrew selects the optimization objective, typically fuel burn, flight time, or a 

weighted combination of fuel burn and flight time. Passenger comfort and avoiding turbulence are also optimization 

considerations of the aircrew. However, due to the general lack of turbulence predictability, Auto mode may not 

have the required information to search for trajectories that minimize turbulence. Instead, the aircrew could use 

Manual mode to evaluate a pilot-specified candidate route or altitude that may avoid turbulence based on ride 

reports. Convective weather regions made known to the TASAR automation could be avoided by an additional 

buffer specified in the configuration settings in Section 4.3 in an attempt to minimize the hazards of convective 

weather. 

Users may also desire to use TASAR automation to minimize overflight fees during international operations. 

Whereas initial TASAR deployment may be limited to operations in the continental United States, future TASAR 

deployments could include international operations with cost functions that minimize overflight fees. 

(c) Threshold for Aircrew Notification 

When operating in Auto mode, the automation will use a pilot-specified threshold for each objective (e.g., 

pound of fuel saved) for notifying the aircrew of an available trajectory change that sufficiently improves the 

objective. For weighted cost functions, each entity would have a settable threshold, rather than using a threshold for 

the entire weighted cost function. The aircrew may not have an intuitive feel for changes in the weighted cost 

function but will want to be notified if there has been a minimum improvement in either fuel or time. 

(d) Desired Trajectory 

Using Manual mode, the aircrew enters a desired trajectory change. This change could consist of a revised 

lateral path, an altitude change, or combination lateral/altitude change. For lateral path changes, the aircrew enters 

off-route named waypoints if desired and a reconnect point on the existing route, or the aircrew could enter just a 

downstream waypoint for a “direct to” request. 

Aircraft generally need to be on an arrival route at some point prior to the destination airport. This procedure is 

specific to each destination airport, and generally larger airports require aircraft to be on the arrival route farther 

upstream of the airport. By default, the Auto mode will reconnect at or prior to the first fix on the arrival procedure 
8 

on the originally filed route. If desired, or if the TASAR automation is unaware of the procedure, a pilot could 

specify a different waypoint to reconnect based on the pilot’s experience. This parameter is only applicable to Auto 

mode, since the pilot specifies the named waypoint where the reconnect occurs in Manual mode. 

4.3. Additional Input Parameters 

The parameters described in this section could be included if research or operational use indicate their utility. 

They may be additional aircrew inputs or could be specified in pre-flight configurations to help define the behavior 

of the TASAR automation. Configuration parameters would not normally be updated by the aircrew since they are 

more general than a single flight and are intended to generally represent the policies and procedures of the operator. 

(a) Time Constraint 

The aircrew may be subject to arrival time constraints at the destination airport, and the primary optimization 

objective may be to minimize deviation from or not exceed a scheduled arrival time. Examples include block time 

for the aircrew, airport curfew, gate availability, and passenger connections. The TASAR automation could apply a 

high penalty to the objective function if these time constraints are not achieved. 

Generally, the TASAR automation would not consider a time constraint by default. If the aircrew enters a time 

constraint, only solutions where the aircraft is projected to arrive at or before the time constraint would be presented 

to the aircrew, assuming the TASAR automation is able to find solutions that satisfy the time constraint. If the 

TASAR automation cannot find solutions that satisfy the time constraint, then trajectory changes would be presented 

that minimize deviation from the scheduled time. 

(b) Reserve Fuel Constraint 

The aircrew must ensure that certain constraints such as fuel reserves are not violated, since the violation of 

these constraints could impact flight safety. TASAR procedures will specify that the aircrew determines the 

acceptability of a request with respect to fuel reserves before making the request. The aircrew also coordinates with 

the dispatcher as required by standard operating procedures. TASAR automation is not intended to supplant existing 

systems and procedures for reserve fuel calculations or to display fuel reserve information. 

(c) Traffic Separation Buffer 

Whereas TASAR automation would apply standard separation criteria in its conflict probe of possibly trajectory 

changes, a configurable buffer could expand the conflict probe’s parameters for preventing conflicts. The buffer 

parameter would account for: (1) separation margin for increased controller acceptability, (2) different ownship 

trajectory predictions between airborne and ground systems, (3) surrounding aircraft trajectory uncertainties, (4) 

atmospheric and wind modeling differences between the air and ground, and (5) differences between ADS-B and 

ground-based surveillance. The buffer would be a configuration parameter not adjusted by the aircrew in flight. 

(d) Hazard Separation Distance 

The configuration could specify minimum desired separations to hazardous convective weather and special 

activity airspace (SAA). The aircrew could also define the threshold for convective weather based on, for example, 

NEXRAD reflectivity. 

(e) Optimization Update Rate for Auto Mode 

An optimization update rate parameter would specify how often the TASAR automation computes trajectory 

changes while in Auto mode. Reoptimizing accounts for: (1) trajectory changes of other aircraft, (2) changing 

winds, convective weather, temperature, and other atmospheric conditions, (3) SAA activation schedule changes if 

available, and (4) aircraft weight changes due to burned fuel. 
9 

4.4. Automated Information Gathering 

The TASAR automation would gather traffic and hazard information using automated retrieval with no required 

aircrew action other than possibly powering up the system. 

(a) Airborne Surveillance through Various Sources 

TASAR automation will have knowledge of other aircraft through air-to-air ADS-B, ADS-B Rebroadcast 

(ADS-R), and TIS-B. Aircraft ADS-B equipment will use either the 1090 Megahertz (MHz) (1090 MHz Extended 

Squitter – 1090ES) or the 978 MHz (Universal Access Transceiver – UAT) radio frequency. The 1090ES will be 

used in all airspace, while UAT will be used below 18,000 ft MSL to correspond with the ADS-B rule requirements. 

Class A airspace above 18,000 ft MSL will contain 1090ES aircraft only, while all other classes of airspace will 

contain a mixture of 1090ES and UAT aircraft. Depending on the ADS-B receiving capability of TASAR aircraft, 

surveillance information from some aircraft may not be received if they are on the opposing frequency and other 

ADS-R or TIS-B broadcast requirements are not met. TASAR aircraft equipped with multi-mode receivers would 

directly receive ADS-B messages from all 1090ES and UAT aircraft within range. 

All ADS-B OUT equipped aircraft will broadcast state vector and mode status information, while aircraft 

equipped with ADS-B IN may also broadcast an air referenced velocity information. The state vector report 

includes the current latitude, longitude, geometric altitude, pressure altitude, north and east components of the 

horizontal velocity, and the vertical rate of the ADS-B target aircraft. The mode status report provides target aircraft 

characteristics such as broadcast capabilities and the quality of the broadcasted state vector data. The air referenced 

velocity report provides the airspeed and heading while airborne. Trajectory change reports that provide near-term 

4D aircraft intent may not be broadcasted, depending on current FAA regulations . 

(b) Surveillance through Airborne Internet 

Aircraft equipped with airborne internet access could use surveillance data available over an airborne internet 

connection to overcome limitations caused by incomplete ADS-B equipage, ADS-B equipment range, and lack of 

planned future 4D trajectories in ADS-B reports. The Aircraft Situation Display to Industry (ASDI) is one source of 

surveillance data that the FAA provides to subscribers to increase situational awareness. ASDI combines radar, 

ADS-B, and flight plan information from across the National Airspace System (NAS) into a single source of 

surveillance data. The ASDI messages most relevant to TASAR automation are the radar track update (TZ), flight 

plan (FZ), and flight plan amendment (AF) messages. The TZ message contains the flight identifier, latitude, 

longitude, altitude, and groundspeed. The FZ message contains the flight identifier, aircraft type, airspeed (true or 

Mach), proposed departure time, requested altitude, route of flight, and estimated time of arrival. Flight plan 

amendments contain altitude and route updates. 

Use of ASDI information by airborne systems has a number of limitations, including latency and quantity of 

data. Radar track data is updated at one minute intervals and could be delayed by five minutes or more before being 

downloaded from the internet, due to security requirements and other latency issues. Also, ASDI data is not filtered, 

so the aircraft could be sent a large volume of information with many flights that have no impact on the current 

trajectory of the aircraft. This issue could be mitigated by developing a separate system on the ground that filters 

data before sending to the aircraft. Airborne internet may have bandwidth limits to consider when the aircraft is 

downloading data. Also, ASDI messages are sent out continuously and flight plan and amendment information is 

only sent out once unless there is a change. Automation will not have access to these flight plans and amendments 

unless the automation is powered on and receiving data over the internet when the flight plans and amendments are 

sent. 

(c) Hazard Information 

Convective weather information would be available to the TASAR automation through onboard weather radar, 

airborne internet (if equipped), satellite weather, and Flight Information System Broadcast (FIS-B) (UAT or multimode ADS-B IN equipped aircraft only). Onboard weather radar is capable of detecting significant convection and 

lightning strikes at 200 nmi or more from the aircraft to provide an indication of the current weather in the forward 

direction of the aircraft. Satellite weather and FIS-B provide both provide NEXRAD reflectivity, which provides an 
10 

indication of current weather conditions, and convective Significant Meteorological Information (SIGMETs), which 

provide forecasted convection. 

Special activity airspace status is available through FIS-B and over the internet to aircraft equipped with 

airborne internet access. The TASAR automation will rely on published databases for terrain hazards since these 

hazards are not dynamic. Turbulence will not likely be considered by the TASAR automation initially. However, as 

the availability and quality of turbulence data improves, Auto mode functionality could be augmented to avoid 

current and forecasted turbulence. 

(d) Wind Velocity and Temperature 

The TASAR automation would gather wind velocity and temperature information and real-time updates from 

satellite weather, airborne internet (if equipped), or FIS-B to be used for trajectory optimization purposes. Updated 

wind field information in particular is key to effective trajectory optimization. 

(e) ATC Procedures and Sector Boundaries 

The TASAR automation may include a database of sector structure and letters of agreement between ATC 

facilities. However since they are not dynamic, updates will not be required during flight. 

(f) Traffic Flow Management Initiatives 

The FAA provides on-line tools to share reroute initiatives and active metering locations with airspace users. 

The websites do not provide flight-specific information, but it may be possible to determine if a flight will be 

impacted by the initiative. Aircraft equipped with onboard internet could have access to this information. 

The TASAR onboard automation may also dynamically compute sector congestion to determine where traffic 

flow management initiatives may exist. The monitor alert parameter indicates to traffic managers when a sector 

may be approaching capacity and an initiative may be required. The monitor alert parameter may be dynamically 

modified based on weather conditions and complexity of traffic flows in the sector. If these modifications are not 

available outside of FAA facilities, the nominal monitor alert parameter value could be used by the TASAR 

automation to estimate sector congestion. Sector traffic counts (which may be incomplete before the ADS-B 2020 

mandate) in nearby sectors could be dynamically constructed from airborne surveillance through ADS-B and TIS-B. 

4.5. Dispatch Integration 

TASAR automation may be integrated with Airline Operations Center (AOC) dispatch automation to help the 

aircrew make better requests and to keep dispatchers informed of aircrew actions. This section describes potential 

information sharing between the TASAR automation and dispatch which could be done over airborne broadband 

internet or another protocol. 

(a) Updated ATC Information 

Dispatch could have updated ATC traffic flow management (TFM) information that could influence which 

aircrew requests would be granted by ATC. For example, dispatch could be aware of a reroute initiative that has 

recently ended, and providing that information to the TASAR automation could result in the aircrew making a 

request that improves their objectives. 

(b) Dispatch Directs Aircrew to make Trajectory Change Request 

Dispatch may leverage fleet optimization and surveillance information functions on the ground to identify 

aircraft that could improve their trajectories or otherwise improve fleet operations. Once these aircraft are 

identified, dispatch could send messages to the aircrew or directly to TASAR automation indicating either a change 

in optimization objective or a specific trajectory change request to make to the controller. For the former, the 

aircrew updates the optimization objective in Auto mode, and the TASAR automation proceeds to seek trajectory 

changes for this new objective. For the latter, the aircrew would use Manual mode to probe the request for conflicts 

and other factors that influence acceptability of the request to the controller. In effect, the dispatcher is leveraging 
11 

the onboard TASAR automation to “time” the desired request to ATC such that approval is more likely, thereby 

increasing the effectiveness of the dispatcher’s flight optimization capabilities. 

(c) Aircrew Request Coordination with Dispatch 

Dispatch may wish to be informed of potential aircrew requests to (1) verify that a gate at the destination airport 

will be available if the aircraft arrives early, (2) check the impact on the fleet such as sequencing of flights at the 

arrival fix, or (3) verify that the requests improve the objectives of the operator based on the most up-to-date 

information onboard the aircraft (e.g., actual aircraft weight). Coordination with dispatch could be via automated 

downlink of the requested trajectory so that aircrews and dispatchers do not experience additional workload. 

4.6. Probing for Trajectory Changes 

This section describes the desired functions and behavior of TASAR automation when generating a more 

efficient trajectory. 

(a) Degrees of Freedom for the Trajectory Change 

The TASAR automation will search through the degrees of freedom listed in Table 4-1. The left column lists 

the objectives and constraints to be met by the trajectory change in the middle column. Examples of the trajectory 

change given in the right column of Table 4-1. Lateral and altitude trajectory changes need to be requested, while 

speed changes do not need to be requested (only reported if the speed change exceeds five percent of current 

airspeed or 10 knots, whichever is greater). However, if a controller issues a speed clearance, the aircrew must 

request deviations from the clearance. 

Table 4-2 Trajectory Changes 

Aircrew Objective(s) 

& Constraint(s) Trajectory Change Examples 

Objectives: 

Minimum fuel and 

minimum time 

Lateral route change to shorter wind optimal route. Will 

minimize fuel and time simultaneously. 

Direct to downstream waypoint. 

Switch to alternative route. 

Sequence of waypoints. 

Request another arrival fix. 

Constraint: 

Avoid hazards 

Lateral route change that avoids convective weather and 

SAA by buffer specified by aircrew inputs. This is 

intended to be a more strategic change when conditions 

allow a route change as opposed to a heading change. 

10 nmi parallel offset left of 

current track. 

Same examples as lateral route 

changes above. 

Objectives: 

Minimum fuel OR

minimum fuel and 

minimum time 

Change altitude to reduce fuel burn but increase flight 

time (decrease groundspeed) OR change to altitude with 

sufficient tailwinds to reduce both fuel burn and flight 

time (increase groundspeed). Aircraft may have been at 

a less desired altitude due to optimal winds that have 

now shifted, altitude restrictions that have been lifted, or 

fuel weight that has been burned off during the flight. 

Request FL330 when flying 

FL290. 

Constraint: 

Avoid hazards 

Climb to higher altitude to avoid convective weather or 

terrain. Icing hazards can also be avoided by selecting 

another altitude. 

Request FL330 when flying 

FL290. 

Objective: 

Minimum fuel 

Increase or decrease airspeed closer to maximum-range 

cruise that minimizes fuel burn. 

Request Mach 0.78 when flying 

Mach 0.80. 

Objective: 

Minimum time 

Increase airspeed above maximum-range cruise to make 

up time. 

Request Mach 0.82 when flying 

Mach 0.78. 

Constraint: 

Avoid hazards 

Decrease airspeed to mitigate effect of turbulence. Request decrease in speed from 

Mach 0.82 to Mach 0.80. 

Shifting winds, fuel burned off during flight, changing aircrew priorities during flight, and previous assignment 

to a suboptimal trajectory will cause an aircrew to desire a lateral, altitude, speed, or combination of these as a 

trajectory change to be requested. Trajectory changes using lateral, altitude, speed, or a combination may also be 
12 

used to avoid hazards and surrounding traffic. However, the primary consideration is to generate trajectories to meet 

the combined objectives of the aircrew. 

(b) Conflict Probe 

The TASAR automation considers the following information when probing candidate trajectories for conflicts 

with other aircraft or hazards. Both Auto and Manual modes would use the same conflict probe functionality. 

 Ownship trajectory: Creates a four-dimensional trajectory from the TASAR-capable aircraft’s state and 

intent. Flight mode segments are generated using the aircraft’s flight plan, guidance modes, autoflight 

settings, and a performance model of the aircraft. 

 Surrounding traffic trajectories: Creates a four-dimensional trajectory prediction for each known traffic 

aircraft. If the flight plan is not known for an aircraft, or the aircraft is not following their flight plan, the 

prediction is based on the aircraft following their current heading, speed, and vertical rate. If the flight plan 

is known for an aircraft, the prediction is based on following the sequence of waypoints using current speed 

or the best information available. 

 Hazards: Static or dynamic regions of airspace that the aircraft must avoid or that the pilot prefers to avoid 

will be accounted for by the trajectory optimization function. 

 Buffers around other aircraft and hazards: A conflict is indicated if the ownship (or its buffered location) is 

predicted to come within a specified lateral/vertical volume of any traffic aircraft (or its buffered location) 

or breach the boundary of any hazard area. 

 The conflict probe would be configured to be consistent with current controller conflict probing look-ahead 

times. Generally, the onboard automation would probe approximately to a 10-minute look-ahead horizon. 

This shorter term probing is intended to improve acceptability to the current sector controller. Longer lookahead horizons may reduce conflicts in the next sector but may also be succeptable to higher uncertainty 

from the longer-term trajectory predictions. If a conflict would be created in the next sector, the optimized 

trajectory change may be modified in order to prevent the conflict. The TASAR onboard automation may 

consider the tradeoff between the probability of a conflict and the impact on the preferred trajectory of the 

aircraft if the conflict occurs. 

(c) ATC Procedures 

Letters of agreement between adjacent ATC facilities impose constraints that restrict the trajectory (speed, 

altitude, heading, or route) of aircraft when transitioning across facility boundaries in order to manage traffic flows. 

These agreements are not readily accessable to the user community but could be leveraged by TASAR automation if 

made available by database or other means. If these constraints are available, the Auto mode search could favor 

trajectory changes that are consistent with ATC letters of agreement. Similarly, Manual mode could inform the 

aircrew of any potential issues with known ATC constraints. 

The following are possible TASAR considerations of ATC procedures involving facility letters of agreement: 

 Controllers have less freedom to grant requests that violate letters of agreement than other restrictions. 

Auto mode may be configured so that generated requests attempt to avoid violating letters of agreement in 

most cases. 

 Controllers are unlikely to grant requests during initial climb since these requests may conflict with arrival 

flows. However, when the aircraft reaches the high altitude structure, there is opportunity for granting 

requests, especially if the aircraft is far enough from the destination airport to not be impacted by metering 

restrictions. Auto mode could be configured so that requests are not generated below cruise altitudes. 

 Requests for wrong altitude for direction cause additional workload for the controller to coordinate with the 

adjacent sector. Auto mode could be configured so that requests that involve wrong altitude for direction 

are not generated. Alternatively, the aircrew could be warned that requests for wrong altitude for direction 

are less likely to be granted. 

 The distance upstream of the arrival fix where the aircraft merges into the arrival stream depends on the 

size of the airport. It is more acceptable to connect into the arrival route close to the arrival fix for small 

hub airports, while large hub airports generally require aircraft to be on the arrival route further out from 

the arrival airport. Auto mode requests could consider the first fix on the arrival procedure, as discussed in 

Section 4.2 (d), when generating lateral requests that reconnect to the arrival route. 
13 

 Controllers typically will not grant requests after initiating hand-off status with the next sector. The 

TASAR automation could consider sector boundary information and indicate to the aircrew when the 

aircraft is estimated to be within a threshold distance of the sector boundary and aircrew requests are less 

likely to be granted. 

 Not all controller routine behaviors are included in facility standard operating procedures. Over time, 

sector controllers develop methods to cope with traffic. The TASAR automation is not intended to infer 

controller behavior in this case. 

(d) Traffic Flow Management Initiatives 

TFM initiatives including metering and reroutes may be considered by TASAR automation. Metering may 

include miles-in-trail (distance-based) or required time of arrival (time-based) metering. TASAR automation may 

inform the aircrew that the aircraft may be part of metering when approaching congestion and that there could be a 

reduced likelihood of the request being granted. 

The TASAR onboard automation may also detect congested sectors as described in Section 4.4. Controllers 

will generally avoid sending traffic through an adjacent sector that is congested but may not be aware of congested 

sectors further away. If an aircrew request trajectory goes through an adjacent sector that it congested, it is likely to 

be rejected. However, if the aircrew request trajectory goes through another congested sector that is not adjacent to 

the current sector, then the request may be approved but the aircraft trajectory may be changed later to a less 

preferred trajectory to avoid the congested sector. Since the TASAR automation may not have the capability to 

accurately predict the trajectories of other aircraft to a longer time horizon, it is likely that TASAR automation 

would only consider congestion in the adjacent sector and possibly the sector beyond that during the Auto mode 

search. Manual mode may advise the aircrew if a trajectory change is projected to go through congested sectors. 

However, the ability to predict sector congestion depends on complete surveillance of the surrounding traffic. 

Predicting sector congestion may not be a useful function without means to receive data on all traffic regardless of 

ADS-B equipage. 

An aircraft may also be part of a reroute initiative to avoid weather or mitigate more strategic sector congestion. 

In this case, the pilot will be aware if it is acceptable to make a request. Auto mode functionality will continue to 

search for trajectory improvements when the aircraft is part of a reroute initiative in order to provide the flexibility 

to the pilot to send a request if desired. 

(e) Facilitating Voice Communications 

Voice communication places practical restrictions on the complexity of aircrew requests. Section 4.2 proposed 

that the aircrew dynamically select a maximum complexity (i.e., number of elements in the request) depending on 

the situation. The default complexity is expected to be limited to two off-route waypoints. Combination altitude 

and lateral requests must be made simultaneously and may be limited to one off-route waypoint in addition to the 

requested altitude. 

When generating waypoints, the TASAR automation restricts the trajectory to named waypoints to facilitate 

voice requests. These named waypoints will be considered along with other trajectory changes in the following 

order of preference from most preferred trajectory change to least preferred trajectory change: (1) named high 

altitude VORs (Very-high-frequency Omnidirectional Range) and fixes, (2) named low altitude VORs and fixes, (3) 

parallel offset from current track or airway, and (4) desired heading or range of headings. 

Due to technical limitations, the controller workstation may not have all waypoints in a database readily 

available to the controller. If the waypoint is not in the database, the controller may need to manually enter the 

details of the waypoint which is a time consuming process. The TASAR automation will only develop lateral route 

requests that contain waypoints in the database. The database is center-specific, and so the TASAR automation 

would update available waypoints upon crossing a center boundary. 

4.7. Displaying Trajectory Change to Aircrew 

If the TASAR automation incorporates sector boundary information, only trajectory changes that begin in the 

current sector will be displayed to the aircrew, since controllers are primarily concerned with trajectory changes that 
14 

occur in their sectors. Generally, trajectory change requests should not be made more than one or two minutes prior 

to the start of the trajectory change. Trajectory changes that occur downstream of the current sector would be 

presented to the aircrew when the aircraft enters the downstream sector where the proposed trajectory change will 

occur. The following subsections describe information that would be presented to the aircrew. 

(a) Standby until Minimum Altitude 

The TASAR automation displays a standby screen until the aircraft reaches an altitude at or above 10,000 ft 

MSL to correspond with the behavior described in Section 3.3. 

(b) List of Trajectory Changes that Improve Objectives (Auto Mode) 

A list of trajectory changes that improve the objectives of the aircrew and avoid hazards and traffic will be 

presented. Only those trajectory changes that are sufficiently free of conflicts and are determined to be otherwise 

acceptable to controllers will be presented to the aircrew. Once the aircrew makes the request to the controller, the 

aircrew has the option of freezing the requested trajectory change to prevent further updates. 

(c) Modifications for Conflict-Free Pilot-Specified Preferred Trajectory (Manual Mode) 

If the pilot enters a trajectory that does not avoid hazards or other traffic, then modifications to make the 

trajectory conflict free are presented at pilot request. 

(d) Outcomes of Trajectory Change (Auto and Manual Modes) 

The predicted change in fuel burn and flight time will be presented to the aircrew. The predicted distance to 

hazards and other traffic will not be presented to the aircrew since the trajectory changes presented will be at least 

the minimum required distance plus any buffers. 

(e) Conformance with Standard Procedures and Letters of Agreement (Manual Mode) 

If a trajectory change is not consistent with ATC standard procedures or violates a letter of agreement between 

facilities, the aircrew would be notified of the issue with the trajectory change entered by the aircrew. TASAR may 

also indicate if a request has a reduced likelihood of approval due to, for example, the aircraft being in handoff 

status to the next sector controller or the aircraft being too close to the destination airport. 

(f) Traffic Management Initiatives (Manual Mode) 

It may be desirable to inform the aircrew that the aircraft is part of a metering situation or reroute initiative, or 

that the trajectory change is projected to enter congested sectors. 

(g) Time to Trajectory Change (Auto and Manual Modes) 

The time to the location where the trajectory change should occur is presented to the aircrew. If not presented, 

the trajectory change is assumed to be immediate. 

4.8. Aircrew Request Negotiation with Controller 

The aircrew (not the TASAR automation) decides when a request is appropriate and makes a request to the 

controller. The response to controller approval, deferral, denial, or amendment is as follows. 

(a) FMS Verification 

Prior to issuing a TASAR request, the aircrew will use the FMS to verify that the TASAR request is flyable and 

will improve the objectives of the aircrew. Due to different aircraft performance models and atmospheric 

information between the TASAR automation and the FMS, it is possible that the TASAR automation may identify a 

trajectory change it estimates as beneficial while the FMS may indicate that executing the request would not be 

beneficial. If there is disagreement between the TASAR automation and the FMS, the FMS should be used as the 

authoritative source. Pilots may have the option to enter updated information into the FMS (e.g., winds) in order for 

the FMS to recognize that a TASAR generated request is beneficial. 
15 

(b) Confirm with Dispatch 

Company policies regarding pilot/dispatcher coordination of flight plan changes are not altered by TASAR. 

Where required, this coordination could be automated through TASAR as described in Section 4.5. 

(c) Approval 

If the request is approved by ATC, the aircrew will execute the trajectory change. The TASAR automation will 

detect that the trajectory change has been executed and start computing trajectory changes relative to the executed 

trajectory change. The TASAR interface may provide means for the pilot to record the request was approved, 

deferred, denied, or amended. 

(d) Deferral 

If the controller defers the request, the TASAR automation continues to compute the optimization objective 

function without developing modifications to produce a trajectory free of conflicts. If the trajectory change is no 

longer optimal, the aircrew will use their best judgment to determine whether to cancel the request. 

(e) Denial 

The TASAR automation will not be updated in response to a controller denial of a request since the controller is 

unlikely to communicate why the request was denied. Instead, the potential requests presented to the aircrew will 

continue to be updated as the flight progresses. 

(f) Amended Trajectory 

Generally, a pilot will know if the ATC amendment is still advantageous and will be able to accept or reject the 

amendment without automation assistance. However, entering an ammended trajectory change offered by ATC into 

the TASAR automation using Manual Mode will be an option for the pilot to verify if the amended trajectory change 

is desired. 

4.9. Benefits to be Realized 

A preliminary fast-time simulation study showed that, on average, aircraft equipped with TASAR can reduce 

travel time by about one to four minutes per operation and fuel burn by about 50 to 550 lbs per operation, 

depending on the objective of the aircrew, class of airspace user, and aircraft type.2 Benefits are estimated to be 

higher at longer stage lengths since beneficial trajectory changes can be applied over a longer distance. The benefit 

mechanisms that elicit these benefits are discussed in this subsection. 

A benefit mechanism is a causal linkage that converts a function into a benefit by applying the function to 

mitigate inefficiencies. Probing desired trajectory changes for possible separation violations with nearby traffic is 

one function for the benefit mechanism shown in Figure 4-1. This function is expected to mitigate the issue that 

aircrew requests are not always conflict free and are therefore sometimes denied. The other function shown in 

Figure 4-1 is the capability for TASAR-equipped aircraft to generate user-preferred trajectories, which mitigates the 

issue that the aircraft may not be following their preferred trajectory due to a previous inefficient trajectory 

assignment, a change in flight priorities, or a change in the environment (e.g., winds or weather). 

The mechanisms shown between the first and second vertical dashed lines are enabled by these two functions 

and result in the four benefits shown between the second and third vertical lines in Figure 4-1. 

The five benefits shown are: (1) aircrew better able to meet their objectives (delay, fuel costs, passenger 

comfort, etc.), (2) improved National Airspace System (NAS) performance, (3) reduced nuisance requests, and (4) 

reduced conflicts for controller to resolve. In order to quantify these benefits, four metrics are shown in boxes with 

dashed lines in Figure 1. These metrics are, respective to the four benefits: (1) aircrew utility, (2) NAS-wide delays, 

fuel burn, and congestion, (3) aircrew requests rejected by the controller, and (4) conflicts resolved by controller. 
16 

Figure 4-1 TASAR Benefit Mechanisms 

Potential negative impacts of TASAR on the NAS are also considered, in addition to the benefits described in 

the previous subsection. Figure 4-2 shows potential impact mechanisms in a format similar to the benefit 

mechanisms shown in Figure 4-1. Four possible impacts are: (1) potential for increased controller workload if 

TASAR equipage grows too rapidly, (2) potential for increased user request denials if TASAR requests use 

insufficient margins of separation, (3) increase in conflicts to be resolved by the controller, and (4) potential for 

increase in airspace complexity. The expectation is that TASAR will reduce the conflicts for controllers to resolve, 

but there may be cases where TASAR resolves the immediate conflict but the resulting traffic situation may cause a 

controller downstream of the current sector to deal with more conflicts overall. 

Figure 4-2 Mechanisms for Potential Negative Effects of TASAR 
17 

TASAR may provide two important benefits in meeting the challenge of airspace system modernization. (1) Its 

near-term operational use will provide a better technical understanding of ADS-B surveillance and its use by 

onboard automation, leading to the development of advanced concepts that involve a high degree of aircraft and 

flight crew autonomy. The development of TASAR should also provide a better understanding of the data and 

computational needs of the aircrew when planning their trajectory to meet their objectives. (2) Perhaps more 

importantly, TASAR may provide a user incentive for equipping aircraft with ADS-B, thereby accelerating equipage 

in advance of the 2020 ADS-B Out equipage mandate. Given the 2020 mandate, it is assumed that aircraft will 

equip with ADS-B Out when equipping with ADS-B In to obtain the TASAR single aircraft benefits. 
18 

5. Potential Evolution Paths for TASAR 

TASAR will need to evolve to be consistent with future NAS operations and to take advantage of the Next 

Generation Air Transportation System (NextGen) operational improvements. Operational improvements that are 

presented in this section were obtained from the National Airspace System Enterprise Architecture (NAS EA) 

website (https://nasea.faa.gov/). 

5.1. 4DT Negotiation via DataComm 

Initially, TASAR requests will be limited to named waypoints over voice communications. The introduction of 

data communications (DataComm) will allow for more complex TASAR requests, such as waypoints defined by 

latitude and longitude, to allow the aircraft to more closely follow the preferred trajectory of the operator. 

DataComm will eventually be used in NextGen to transition from routes defined by named waypoints to fourdimensional trajectories (4DTs) defined by three-dimensional spatial locations and time. TASAR algorithms would 

generate modifications to 4DTs including new fix time objectives in their definition to facilitate trajectory 

negotiation. 

5.2. Flight Deck Planning with ANSP Feedback 

One of the NextGen operational improvements is intended to allow flight crews to do trial planning from the 

flight deck. This trial planning will be enabled by aircraft access to system-wide information management (SWIM) 

and air navigation service provider (ANSP) ground automation tools that provide feedback on constraints impacting 

the trajectory. TASAR could be used as the automation function on the flight deck that generates optimized 

trajectories which are then sent over SWIM or direct downlink to be probed by ground automation. The TASAR 

automation algorithms would then need to revise the optimized trajectory based on feedback received from the 

ground automation tools. 

5.3. Enhanced Flight Plan with Alternative Trajectories and Preferences 

Under NextGen, it is expected that the flight plan will contain information regarding user preferences, such as 

ranked alternative trajectories. These preferences will be used by the ANSP to generate traffic management 

initiatives that better meet the preferences of the airspace users. One potential role for TASAR automation could be 

to continually evaluate these alternative trajectories to search for the most optimal alternative. If better alternatives 

are found, the flight deck planning with ANSP feedback function described in Section 5.2 could be used to evaluate 

the alternatives. 

5.4. Types of Trajectory Constraints 

Time-based metering, point-in-space metering, and 4DTs are all part of a NextGen shift by the ANSP to 

generate traffic management initiatives with flight-specific trajectories. TASAR automation will need to account for 

these types of constraints when generating more optimal trajectories, as well as other NextGen initiatives such as 

delegated separation and performance-based access to airspace and routes. 
19 

6. Operational Scenarios 

This section describes sample scenarios corresponding to the two TASAR modes: Auto mode and Manual 

mode. Each of these scenarios define a range of aircrew objectives, the preconditions that cause the aircraft to be on 

a less desired trajectory, the post conditions after the request is granted, and the steps in the scenario. 

6.1. Sequence for Automated Monitoring for Opportunities (Auto Mode) 

Aircrew objectives: 

1) Minimize flight time, OR 

2) Minimize fuel burn, OR 

3) Minimize weighted combination of flight time and fuel burn 

Precondition alternatives that cause the aircraft to be on a less desired trajectory: 

i. Planned route is not wind optimal post-departure, or winds shift during flight, or aircraft changes 

lateral route to cause another altitude to be wind optimal. 

ii. Aircraft is part of a reroute initiative to avoid convective weather or mitigate congestion, and aircraft 

are not shifted back to user-preferred routes after the initiative has ended. Or aircraft is part of an 

altitude capping or tunneling initiative and aircraft is not returned to user preferred altitude after 

initiative has ended. 

iii. Convective weather impacts aircraft en route. This is intended to be a more strategic change when 

conditions allow a route change as opposed to a series of ad hoc heading changes. Or convective 

weather is projected to impact current trajectory and aircraft is capable of climbing over convective 

weather by required buffer. 

iv. Convective weather shifts allowing a more preferred tactical trajectory change. 

v. Change in activation schedule of SAA while aircraft is airborne. 

vi. Aircraft is at a lower altitude than desired to minimize fuel burn. Aircraft burns off weight during 

flight to allow climbing to a higher, more fuel efficient altitude. 

vii. Aircraft is destined for a smaller airport (e.g., TEB) but is caught in an arrival stream of a larger airport 

(e.g., JFK) causing the aircraft to be flying slower than desired. Higher altitude is desired to bypass 

larger airport arrival stream. 

Post conditions after request approved: 

1) Aircraft following approved, more optimized trajectory 

2) Utility of operator increased 

Main Scenario: 

1. Flight crew receives initial flight plan from dispatcher. 

2. Flight crew receives initial business objectives for the TASAR automation from dispatcher if dispatcher 

provides business objectives. Otherwise, the flight crew will select a default configuration for the TASAR 

automation in step 7. 

3. Flight crew enters flight plan into FMS. 

4. Aircraft departs and is flying IFR cruise in en route airspace. 

5. Onboard TASAR automation becomes active once the aircraft is above 10,000 ft MSL. 

6. TASAR automation receives current flight plan from FMS. 

7. Flight crew enters initial objectives into TASAR automation or uses a default TASAR automation 

configuration. 

8. TASAR automation is in Auto mode by default. 

9. TASAR automation receives updates (if any exist) from flight operational control or internet source (if 

equipped). 

10. Flight crew receives updated objectives from dispatcher (if objectives have changed). 
20 

11. Flight crew enters updated objectives into TASAR automation (if objectives have changed). 

12. TASAR automation receives updated position/state of aircraft equipped with ADS-B Out as well as 

aircraft not equipped with ADS-B Out from TIS-B. 

13. TASAR automation receives updated weather, winds, and atmospheric information from satellite weather, 

FIS-B, or internet depending on aircraft equipage. 

14. TASAR automation receives updated SAA activation schedule from FIS-B or internet depending on 

aircraft equipage. 

15. Preconditions i to vi 

16. TASAR automation identifies aircraft is not following preferred business trajectory to meet flight 

objectives. 

17. TASAR automation creates a 4D trajectory prediction for the ownship as well as all aircraft known 

through ADS-B. 

18. TASAR automation identifies conflict-free (to a time horizon) lateral, altitude, or combination lateral and 

altitude trajectory change that improves objective. 

19. TASAR automation indicates to flight crew that threshold for making request is exceeded. 

20. TASAR automation indicates attributes of the trajectory change to the flight crew. 

21. TASAR automation indicates to the flight crew the estimated time to when the trajectory change will 

occur. 

22. Flight crew selects trajectory change which freezes the TASAR automation from further updates. 

23. Flight crew verifies with FMS that request will improve objectives. 

24. Flight crew verifies that request will not result in a violation of required fuel reserves. 

25. Flight crew makes request to controller. 

26. Controller approves request if acceptable. 

27. If controller approves the request, the flight crew executes the approved request in the FMS and TASAR 

automation receives the updated trajectory from the FMS. 

28. TASAR automation continues searching for trajectories in Auto mode. 

Precondition i (Shifting winds): 

TASAR automation identifies that winds have shifted and preferred lateral trajectory or preferred altitude may 

have changed. 

Precondition ii (Restriction no longer needed): 

Dispatch notifies flight crew or flight crew determines from voice communications with ANSP that route or 

altitude restrictions are no longer needed. 

Precondition iii (Shifting convective weather): 

TASAR automation monitors for growth, decay, or shifting of convective weather to alter a strategic route or 

recommend an altitude change. 

Precondition iv (Shifting convective weather): 

TASAR automation monitors for growth, decay, or shifting of convective weather to allow a tactical heading 

change. 

Precondition v (Activation/schedule change for SAA): 

TASAR automation identifies available SAA airspace that was previously unavailable due to a change in SAA 

activation schedule 

Precondition vi (Change in aircraft ceiling): 

Aircraft burns off sufficient fuel to allow aircraft to climb to a more advantageous altitude. 

Precondition vii (Aircraft caught in slower arrival stream): 

Airspace above aircraft clear enough to allow climb to another altitude and airspeed increase. 
21 

6.2. Sequence for Pilot Initiated Use with Conflict Probing (Manual Mode) 

Aircrew objectives: 

1) Minimize flight time, OR 

2) Minimize fuel burn, OR 

3) Minimize weighted combination of flight time and fuel burn, OR 

4) Minimize turbulence or weather avoidance 

Preconditions that cause the aircraft to be on a less desired trajectory: 

 i to vii. Same as Auto mode. 

viii. Icing impacts aircraft during flight. 

ix. Aircraft is diverted to alternate airport. 

x. Aircraft is delayed en route and needs to make up time. 

xi. Aircraft is impacted by turbulence. 

xii. Conditions at destination airport require diverting to an alternate airport or, for business operators, 

onboard passengers request a change in destination. 

Postconditions after request approved: 

1) Aircraft following approved, more optimized trajectory 

2) Utility of operator increased 

3) Better ride for passengers 

Main Scenario: 

1. Steps 1 to 14 from Auto mode steps in Section 6.1. 

2. Preconditions i to xii 

3. Aircrew enters desired lateral, altitude, or speed trajectory change into FMS or onboard TASAR 

automation. 

4. If trajectory change is entered into FMS, TASAR senses the trajectory change. 

5. TASAR automation creates a 4D trajectory prediction for the ownship as well as all aircraft known 

through ADS-B. 

6. TASAR automation probes for conflicts. TASAR automation develops conflict-free (to a time horizon) 

modification if necessary. 

7. TASAR automation checks for violations of standard procedures or letters of agreement. TASAR 

automation notifies flight crew of any violations. 

8. TASAR automation indicates attributes of the trajectory change to the flight crew. 

9. TASAR automation indicates to the flight crew the estimated time to when the trajectory change will 

occur. 

10. Flight crew verifies with FMS that request will improve objectives. 

11. Flight crew verifies that request will not result in a violation of required fuel reserves. 

12. Flight crew makes request to controller. 

13. Controller approves request if acceptable. 

14. If controller approves the request, the flight crew executes the approved request in the FMS and TASAR 

automation receives the updated trajectory from the FMS. 

15. TASAR automation continues searching for trajectories in Auto mode. 

Precondition xii (Diverting to alternate airport): 

1. Aircrew selects option from TASAR automation to search for alternative destination airports. 

2. TASAR automation develops list of alternative airports that are reachable. 

3. Aircrew selects desired alternative airport. 

4. TASAR automation displays lateral trajectory to destination airport. 
22 

7. Definitions 

1090 MHz Extended Squitter (1090 ES): Extended Squitter Automatic Dependent Surveillance-Broadcast 

equipment operating on the 1090 Megahertz radio frequency. 

Automatic Dependent Surveillance-Broadcast (ADS-B): A surveillance service using the automatic transmission 

of an aircraft's or surface vehicle's position and other state information. The source of ADS-B information is 

derived from the aircraft's navigation system (e.g., Global Navigation Satellite System receiver, Flight Management 

Computer, etc.). Other aircraft may receive this information and compare it to their own position to accurately 

determine relative position. Ground systems may also use ADS-B information to augment or replace less accurate 

radar-based surveillance information, or to provide cost effective surveillance coverage in non-radar airspace. 

ADS-B Report: An ADS-B Report contains the information elements assembled using messages received from a 

transmitting participant. These information elements are available for use by applications external to the ADS-B 

system. 

ADS-B Message: An ADS-B Message is a block of formatted data that conveys the information elements used in 

the development of ADS-B Reports. Message contents and formats are specific to the ADS-B data link. 

Airline Operations Center (AOC): Centralized organization staffed by certified flight dispatchers responsible for 

the planning and conducts of airline flight operations. 

Air Traffic Control (ATC): Service by ground-based controllers to separate traffic, organize traffic flow, and 

provide information and other support to the pilot when the controller is able. 

Electronic Flight Bag (EFB): Computing platform on the flight deck designed to reduce paper-based reference 

material and to automate calculations. 

Flight Management System (FMS): Automation to help flight crew guide aircraft along flight plan. 

Instrument Flight Rules (IFR): Flight crew operates aircraft solely by reference to instruments. 

Mean Sea Level (MSL): Mean height of the surface of the ocean. 

Reduced Vertical Separation Minima (RVSM): 1,000 ft minimum vertical separation between flight level 290 

and Flight Level 410. 

Traffic Aware Strategic Aircrew Requests (TASAR): Onboard automation leveraging ADS-B surveillance 

information for the purpose of advising the pilot of traffic compatible trajectory changes that would be beneficial to 

the flight. 

Traffic Alert and Collision Avoidance System (TCAS): Alerts pilots of increased collision risk and, under certain 

conditions, recommends maneuver to reduce risk of collision. 

Traffic Flow Management (TFM): Planning and execution of plans by ATC to maintain demand for airspace and 

airport resources below capacity through use of flow controls such as ground stops, ground delays, metering, and 

rerouting. 

Traffic Information Service Broadcast (TIS-B): Uplink of surveillance information (ground radar or aircraft 

targets on another ADS-B frequency) on ADS-B data link to supplement air-to-air ADS-B surveillance. 

Universal Access Transceiver (UAT): Universal Access Transceiver Automatic Dependent Surveillance – 

Broadcast equipment operating on the 978 Megahertz radio frequency. 
23 

8. References 

1

Ballin, M.G., and Wing, D.J., “Traffic Aware Strategic Aircrew Requests (TASAR)”, AIAA-2012-5623, AIAA 

12th Aircraft Technology, Integration, and Operations Conference (ATIO), Indianapolis, IN, September 2012. 

2

Henderson, J., Wing, D.J., and Idris, H., “Preliminary Benefits Assessment of Traffic Aware Strategic Aircrew 

Requests (TASAR)”, AIAA-2012-5684, AIAA 12th Aircraft Technology, Integration, and Operations Conference 

(ATIO), Indianapolis, IN, September 2012. 
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

Contractor Report

 4. TITLE AND SUBTITLE

Traffic Aware Strategic Aircrew Requests (TASAR) Concept of 

Operations 

5a. CONTRACT NUMBER

NNL12AA06C 

 6. AUTHOR(S)

Henderson, Jeffrey

 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

NASA Langley Research Center 

Hampton, Virginia 23681 

 

 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546-0001

 8. PERFORMING ORGANIZATION

 REPORT NUMBER

10. SPONSOR/MONITOR'S ACRONYM(S)

NASA

13. SUPPLEMENTARY NOTES

Langley Technical Monitor: David J. Wing

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified - Unlimited

Subject Category 03

Availability: NASA CASI (443) 757-5802

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email: help@sti.nasa.gov)

14. ABSTRACT

. 

Aircrews submit trajectory change requests to air traffic control (ATC) to better achieve the operator's preferred business trajectory. Requests are currently 

made with limited information and are often denied because the change is not compatible with traffic. Also, request opportunities can be overlooked due to 

lack of automation that advises aircrews of trajectory changes that improve flight time, fuel burn, and other objectives. The Traffic Aware Strategic Aircrew 

Requests (TASAR) concept leverages Automatic Dependent Surveillance-Broadcast (ADS-B) surveillance information to advise the aircrew of beneficial 

trajectory changes that are probed for traffic compatibility prior to issuing the request to ATC. This document describes the features, benefits, and limitations 

of TASAR automation hosted on an Electronic Flight Bag. TASAR has two modes: (1) auto mode that continuously assesses opportunities for improving the 

performance of the flight and (2) manual mode that probes trajectory changes entered by aircrews for conflicts and performance objectives. The roles and 

procedures of the aircrew and ATC remain unchanged under TASAR. 

15. SUBJECT TERMS

ADS-B; Air traffic control; Electronic flight bag; Route optimization; TASAR

18. NUMBER

 OF 

 PAGES

31

19b. TELEPHONE NUMBER (Include area code)

(443) 757-5802

a. REPORT

U

c. THIS PAGE

U

b. ABSTRACT

U

17. LIMITATION OF 

 ABSTRACT

UU

Prescribed by ANSI Std. Z39.18

Standard Form 298 (Rev. 8-98)

3. DATES COVERED (From - To)

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

411931.02.03.07.13.03 

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

NASA/CR-2013-218001

16. SECURITY CLASSIFICATION OF:

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, 

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

collection of information, including suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and 

Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person 

shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.

1. REPORT DATE (DD-MM-YYYY)

01- 05 - 2013