air-ground integrated concept for surface conflict ... · the next-generation air transportation...

American Institute of Aeronautics and Astronautics

1

Air-Ground Integrated Concept for

Surface Conflict Detection and Resolution

Sai Vaddi*, Victor H. L. Cheng

†, Jason Kwan

‡, and Sandy Wiraadmatja

§

Optimal Synthesis Inc., Los Altos, CA, 94022

The paper deals with an integrated automation system concept for conflict detection and

resolution during airport surface operations. The integration exercise features ground-side

and flight-deck-side automation systems. In addition to the conflict detection and resolution

sub-systems, the integration also considers the planner automation sub-system on the

ground side. Integration is facilitated through information exchange over a datalink between

the tower and the flight deck. The paper presents three different options of integration: (i)

Option A representing an “Alerts Exchanged” mode in which only conflict-related

information is exchanged, (ii) Option B representing an “Intent Exchanged” mode in which

intent information is exchanged, and (iii) Option C representing a “Tightly Integrated”

mode which is a blend of Option A and Option B integration concepts. The paper also lists

out the datalink communication requirements and the automation functional requirements

for each of these concepts. The benefits of integration are illustrated using some examples.

I. Introduction

nsuring the safety of the National Airspace System (NAS) in the face of increasing traffic and congestion is of

utmost significance. The recent dramatic incident between an A380 and CRJ-700 at the JFK airport1 is a stark

reminder of the safety issues affecting the NAS. On the other hand, the FAA’s NextGen Implementation Plan2

recognizes airport congestions as a major problem of the NAS. The plan includes airport expansion plans to build

new runways, extend existing runways to accommodate larger aircraft with higher passenger capacities, relocate

runways to increase lateral separation to allow parallel operations under Instrument Flight Rules (IFR), and build

additional taxiways to accommodate the increased surface traffic. Successful implementation of these expansion

plans means more complex airport layouts for the major airports, and more traffic operating on their surfaces. For

airports with added runways, more flights need to cross active runways. Furthermore, new technologies that improve

runway capacity through reduction in longitudinal separation will reduce the opportunity for active-runway crossing,

compounding the runway-crossing problem. Major airports such as Dallas/Fort Worth International Airport (DFW)

exemplify such complexity with as many as 7 runways.

The Next-Generation Air Transportation System (NextGen) concept3 proposes the use of ground-based

automation to schedule surface traffic and generate 4-dimensional (4D) taxi clearances to enable precise departure

times and limited simultaneous runway occupancy. This move toward 4D surface operations pushes the conflict

detection and resolution (CD&R) need beyond the runway and must include all surface operations. Research has

been initiated to determine the information display requirements for presentation of automated 4D taxi clearances to

the pilot and the ability of the pilot to comply with the 4D clearances. Research has yet to be conducted to determine

the safety impacts of following 4D taxi clearances. It is anticipated that the pilot may be so focused on following 4D

clearances to meet scheduled arrival times that unintentional taxi conflicts may result. If this is the case, taxi conflict

detection capability becomes critical.

Overall the NextGen concept could see different automation systems both on the ground side and the flight-deck

side in order to improve the safety, efficiency, and controller workload associated with airport surface operations.

Some of the ground-side automation systems are: (i) airport surface operations planner, (ii) conflict detection and

resolution system, (iii) conformance monitoring systems, and (iv) displays. Similarly, on the fligh-deck side we

have: (i) conflict detection & resolution system, (ii) flight-deck guidance sub-system, and (iii) the flight-deck

* Senior Research Scientist, 95 First Street, AIAA Member.

† Principal Scientist, 95 First Street, AIAA Associate Fellow.

‡ Research Engineer, 95 First Street.

§ Research Engineer, 95 First Street.

E

12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSM17 - 19 September 2012, Indianapolis, Indiana

AIAA 2012-5645

Copyright © 2012 by Optimal Synthesis Inc. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


2

displays. The focus of the current research is to study the mechanisms for effective integration of these automation

systems.

Section II describes the assumptions on the Communication Navigation and Surveillance (CNS) technologies

and the automation technologies that are expected to be part of the integration exercise. Section III presents the

integration objectives and approach. The integration concepts and requirements are presented in Section IV.

Computer simulations have been developed to support experiments for demonstrating the operational capacity of the

different integration concepts, and Section V provides some illustrative examples.

II. Assumptions on CNS & Automation Technologies

A. CNS Technologies

Table 1 presents a list of candidate CNS technologies relevant to airport operations. Further description of these

technological assumptions is available in Refs. 4 and 5. Datalink-based communication between the tower

automation and the flight-deck automation is crucial for integrating the ground-side CD&R and the flight-deck-side

CD&R.

Table 1. Assumptions on CNS Technologies as Enabler

Near-Term Mid-Term Far-Term

C

Voice Communication between Controllers

and Flight Crew

Used for all communications between controller and flight crew

Expected to be used for all clearance and corresponding acknowledgement communications between controllers and flight crew.

Expected to be used in all critical situations such as conflicts. Role in clearance issuance dependent on far-term concept of operations.

Datalink Communication

between Tower and Flight Deck

None Limited bandwidth datalink suitable for exchanging alerts and intent.

Datalink capable of exchanging complex 4D-trajectory clearances.

N Flight-Deck Navigation

Systems

Inertial Navigation System (INS), Global Positioning System

(GPS)

INS, GPS, Wide Area Augmentation System

(WAAS)

INS, GPS, Ground Based Augmentation System

(GBAS)

S

Flight-Deck Surveillance

None Automatic Dependent

Surveillance-Broadcast (ADS-B)

ADS-B

Airport Surveillance Primary Surveillance

Radar (PSR), Secondary Surveillance Radar (SSR)

PSR, SSR, ADS-B, Multilateration

PSR, SSR, ADS-B, Multilateration

B. Tower Automation Technologies

The tower automation could consist of (i) a planning sub-system, (ii) conformance monitoring sub-system,

(iii) CD&R sub-system, and (iv) a display & User Interface (UI) sub-system. Table 2 presents the assumptions on

the tower automation technologies for the different timeframes. The following sub-sections describe in further detail

each of these automation technologies.

Tower Airport Surface Operations Planners

Among the several airport operational planners that are in different stages of development, NASA’s Spot and

Runway Departure Advisor (SARDA) being developed by the Safe and Efficient Surface Operations (SESO)

research team is a key contender for implementation in the mid-term timeframe. SARDA is being designed to help

tower controllers: maintain a smooth, uninterrupted flow of aircraft moving towards the runway for departure to

maximize runway throughput; keep the departure queue at a minimum without starving it; and reduce runway

crossing wait times. The concept and implementation of optimized airport surface traffic operations has been

presented by SESO researchers in Ref. 6. The concept consists of a spot release planner7 and a runway scheduler

8,9.

In other related efforts, taxiway routing and scheduling algorithms are also being developed by SESO

researchers10,11

.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


3

Table 2. Assumptions on Tower Automation Technologies


Airport Surface Operations Planner

None SARDA Spot Release Planner and Runway Scheduler

Integrated Surface Operations Planner, Collaborative Arrival/Departure Planner

Conformance Monitoring System

None Route Conformance Monitor, 4D-Trajectory Predictions

Trajectory Conformance Monitor, 4D-Trajectory Predictions

CD&R None

Conflict detection technology for taxiway collisions and runway incursions.

Conflict detection technology for taxiway collisions, runway incursions, and wake vortex separation violations

Display

Digital Bright Radar Indicator Tower Equipment (DBRITE), Traffic Display on Airport Surface Map

DBRITE, Traffic and Conflict Alert Display on Airport Surface Map, Electronic Flight Strip for Display of Planner Information

DBRITE, Traffic and Conflict Alert Display on Airport Surface Map, Electronic Flight Strip for Display of Planner Information

In addition to SARDA under the NASA NextGen Concept and Technology Development Project, the SESO

Technical Area has supported several efforts towards the development of surface operation planners. These include

research activities by a GT/MIT/Sensis team and a SJSU/OSI team12

to develop surface trajectory planning

algorithms by considering the constraints and uncertainties of the problem.

Even though SARDA uses a trajectory-based design of schedule, it does not issue trajectories as clearances.

Certain far-term planners issue 4D routes as clearances, where some level of flight-deck automation may be required

to realize these 4D clearances. Trajectory-based operations (TBO) constitute a key mechanism proposed by the Joint

Planning and Development Office (JPDO) in the NextGen Concept of Operations (ConOps)3 for managing traffic in

high-density or high-complexity airspace. Applying this mechanism to surface operations at major airports results in

the use of 4D trajectories to enable safe and efficient surface operations.

Trajectory-Based Surface Operations (TBSO)* use more-precise maneuvers for navigation across runways and

through taxiway intersections to reduce operational uncertainties and improve efficiency. They require 4D surface

trajectories to be cleared by the control tower and executed with high precision by the individual flights. Advanced

CNS are enabling technologies to realize TBSO. When referring to 4D-trajectory (4DT) operations, it is implicitly

assumed that there is already agreement between the Air Navigation Service Provider (ANSP) and the flight deck

(FD) on a 4D trajectory to be executed; this notion of 4D trajectories signifies the conceptual difference from

conventional operations. Full 4D trajectories may imply defining 3D spatial position as a function of time. However,

practical concepts involving 4D trajectories define required times of arrival (RTAs) at selected locations along the

route. For TBSO, the natural locations to specify the RTAs include taxiway intersections, runway intersections, and

hold lines. To assure safe operations, it is important to understand the implications of such 4D trajectories as to how

the complete resulting trajectories would interact among the flights, including all points in between locations where

RTAs are specified. Accurate knowledge of the 4D trajectories will allow the ANSP to more precisely plan the

surface traffic using the automated planner and monitor the operations.

Surface Operation Automation Research (SOAR)13–15

forms the seminal research in surface 4DT operations in a

holistic approach to the problem. It contains a GoSAFE (Ground-Operation Situation Awareness and Flow

Efficiency)16,17

tower automation concept that allows surface operation planning including taxiway route

assignment, runway assignment, taxiway sequencing and scheduling, departure runway scheduling, runway exit

assignment and scheduling, and runway crossing operations. SOAR promotes collaborative automation systems for

the tower18

and the FD19–21

to enable 4DT operations. With the tower automation prototype available, the SOAR

concept had been subjected to Human-In-The-Loop (HITL) evaluation at the FutureFlight Central (FFC) tower

simulator22

at NASA Ames Research Center, where some of the human-factors concerns were studied23–26

.

* The term Trajectory-Based Surface Operations (TBSO) is used interchangeably with what others have referred to

as “Surface Trajectory-Based Operations (STBO).” The reason behind choosing the term TBSO is threefold: (i) the

term for TBSO stresses that the concept is for “surface operations” and is of the “trajectory-based” variety; (ii) the

use of TBSO maintains consistency with previous publications; and (iii) at times the less-informed had

misinterpreted the term “Surface Trajectory-Based Operations” as “operations based on surface trajectories,” which

is not the intended meaning.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


4

Tower CD&R Automation Systems

Current-day operations require the ANSP to specify the taxi routes, control the order of merging at intersections,

sequence runway crossings and departures at the runways, and require the pilots to provide separation visually. To

enhance situational awareness of the ANSP, the FAA is introducing new surface surveillance technologies such as

Airport Surface Detection Equipment – Model X (ASDE-X) 27

and Automatic Dependent Surveillance – Broadcast

(ADS-B)28

, which provide aircraft position data in all-weather situations and support the prediction of future aircraft

trajectories more accurately than before. Other technologies useful for conflict and incursion detection or prevention

include the Airport Movement Area Safety System (AMASS)29,30

and Runway Status Lights31

. The Runway

Incursion Alerting System (RIAS)32

consisting of millimeter-wave radar and pan/tilt/zoom cameras was developed

by QinetiQ. The EUROCONTROL Advanced Surface Movement Guidance and Control System (A-SMGCS)33

concept includes research on optimization of airport taxi scheduling34

. A-SMGCS Level 2 consists of automated

monitoring and alerting functions, and includes the prediction of conflicts on active runways or incursions into

restricted areas. The European Airport Movement Management by A-SMGCS (EMMA) project defined A-SMGCS

operational requirements35

for the ANSP and FD, and other important services such as CNS36

. Further development

of A-SMGCS services, procedures, and operational requirements has been documented as part of the EMMA2

effort37

.

The authors under NASA support have developed a ground-side CD&R automation system 4,5,38,39

focusing on

the development of CD&R algorithms for airport surface operations. To better align the research effort with

NASA’s surface operation research interest, CD&R algorithms suitable for the mid-term timeframe were developed.

The automation system is referred to as “Monitor Airport Environment: Surface Traffic and Runway Operations

(MAESTRO).” In contrast to current-day conflict detection systems, MAESTRO has been designed taking into

account NextGen operational concepts from mid-term and far-term timeframes. Conflicts of interest are Taxiway

Collisions and Runway Incursions. A new conflict alert referred to as “Runway Incursion Situation Alert (RISA)” is

created to actively prevent runway incursions. RISA models those situations that are close to a runway incursion but

do not qualify to be one. A more detailed description of RISA is available in Ref. 39. RISAs can be used to actively

prevent runway incursions. The MAESTRO automation system is driven by surveillance inputs and the outputs from

airport planning systems such as Spot and Runway Departure Advisor (SARDA). MAESTRO consists of three

modules: (i) Trajectory Prediction module, (ii) Conflict Detection module, and (iii) Controller Display module. The

trajectory prediction module generates the 4D-trajectory predictions along with their uncertainty estimates. The

paper develops the framework for both deterministic and probabilistic conflict detection. MEASTRO has been tested

using actual surface traffic data from Dallas/Fort Worth International Airport (DFW). The evaluations indicate

promising performance with zero missed-alerts and few false alarms that are actually close encounters. It is shown

that situations which could potentially become Runway Incursions could be detected as RISAs with a lead-time of

60 seconds..

Tower Conformance Monitoring System

A conformance monitoring system for airport surface operations can serve the following purposes:

Monitor the conformance of an aircraft to a clearance issued by the controller. The clearance could be a 3D

route or a 4D trajectory.

Monitor the conformance of an aircraft to the configuration of the airport, e.g., monitor if an aircraft is

taking off from a runway in the wrong direction.

Monitor the conformance of an aircraft to a desired operational plan of the airport, e.g., monitor if an

aircraft is not expected to realize a Scheduled Time of Arrival (STA).

Mosaic ATM is currently investigating surface trajectory prediction and taxi conformance monitoring under a

NASA-sponsored activity. The Surface Management System (SMS)41

, developed by NASA in cooperation with the

FAA, is a valuable decision-support tool for service providers and NAS users for providing situational awareness of

the airport traffic42

. Researchers from Mosaic ATM used the route generation capability of the Surface Decision

Support System (SDSS)—the SMS testbed fielded by the FAA—to study the feasibility of a conformance

monitoring function43

.

Tower Display

Figure 1 shows a candidate airport map display developed by OSI for planning, situational awareness, and

CD&R display purposes. The display has been integrated with the OSI-developed experimental CD&R automation

system discussed above. The display not only shows conflicts on the airport map, but also lists conflicts and

additional information about conflicts and resolutions in tabular columns above the map.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


5

Figure 1. Airport Map Display for Situational Awareness and Conflict Alerts

C. Flight-Deck Automation Technologies

The current section deals with the flight-deck automation technologies that could have an impact on the airport

surface operations. The flight-deck automation technologies can further be categorized into (i) CD&R sub-system,

(ii) guidance sub-system, and (iii) display and user-interface sub-system. The CD&R sub-system and the guidance

sub-systems implicitly contain certain conformance monitoring requirements. Table 3 presents the assumptions on

candidate flight-deck automation technologies relevant for airport surface operations across the three different

timeframes. The following sub-sections further describe these automation technologies.

Table 3. Assumptions on Flight-Deck Automation Technologies


CD&R None

Conflict Detection for Taxiway Collisions, Runway Incursions, and Low-Altitude Conflicts; Generation of Conflict Resolution Advisories

Conflict Detection for Taxiway Collisions, Runway Incursions, and Low-Altitude Conflicts; Generation of 4D-Trajectory-Based Conflict Resolution Advisories

Guidance None None Guidance Commands for Realizing 4D Trajectories

Display None Airport Situational Awareness Display, Conflict Alert Display, Resolution Advisory Display

Airport Situational Awareness Display, Conflict Alert Display, 4D Trajectory Guidance Commands Display

Flight-Deck CD&R Automation Systems

Previous NASA research activities for improving situational awareness on the flight deck include the Taxiway

Navigation and Situation Awareness (T-NASA) System44, 45

developed at NASA Ames, and the Runway Incursion

Prevention System (RIPS)46, 47

developed at NASA Langley. Researchers at NASA Langley are also building on the

earlier RIPS technologies to develop flight-deck technologies for collision avoidance48

: the Collision Avoidance for

Airport Traffic (CAAT) research49–52

develops technologies, data, and guidelines to enable CD&R in the Airport

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


6

Terminal Maneuvering Area (ATMA) under current and emerging NextGen operating concepts. The research led to

the development of a flight-deck CD&R tool referred to as Airport Traffic Collision Avoidance Monitor (ATCAM).

Currently, there is not a system available (either ground or aircraft-based) that directly provides pilots with alerts

of potential runway conflicts with other traffic49

. A detailed literature survey of the flight-deck CD&R systems is

provided in Ref. 49. Some of these systems are: (i) Runway Awareness and Advisory System (RAAS) developed by

Honeywell International Inc, (ii) SafeRoute™ developed by Aviation Communication & Surveillance Systems

(ACSS), and (iii) PathProx™ developed by Era Corporation in collaboration with NASA.

Flight-Deck Guidance Automation System

The primary purpose of the flight-deck guidance automation is to help the flight crew realize a desired airport

operational plan. The guidance sub-system is an important component of far-term operations where 4D trajectories

could be issued as clearance using datalink. The SOAR concept performs TBSO through collaboration between

tower automation and flight-deck automation system, known respectively as Ground-Operation Situation Awareness

and Flow Efficiency (GoSAFE)18

and Flight-deck Automation for Reliable Ground Operation (FARGO)19–21

. With

GoSAFE issuing the clearances, the FARGO system provides the flight-deck automation functions to execute the

clearances. The SOAR concept is built upon the following coupled assumptions:

1. FARGO can achieve high-precision taxi to meet any reasonable RTAs along a pre-specified taxi route.

2. GoSAFE counts on FARGO’s precision-taxi capability to plan efficient and safe surface operations.

Flight-Deck Display

Figure 2 shows a Head-Up Display (HUD) developed as part of the FARGO automation system. The purpose of

this HUD is to aid pilots in realizing RTAs under 4D-trajectory-based operations. These displays contain

information related to the RTA, Expected Time of Arrival, current speed, and required speed. FARGO also has an

Electronic Moving Map (EMM) display as shown in Figure 3. The entries of tabular column on the left side of this

figure show the taxiway route and RTA requirements for each segment of the route.

Figure 2. FARGO Display

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


7

Figure 3. FARGO EMM Display

III. Integration Objectives and Approach

The primary objective of both the ground-side and air-side surface CD&R systems is to prevent collisions

between two aircraft on the surface and close vicinity of the airport. Therefore, it can be argued that two different

CD&R technologies working together can increase the overall safety if integrated appropriately. The objective of the

integrated CD&R concept is exactly to realize the abovementioned objective. However, the two CD&R systems

should not be integrated without giving due regard to other relevant considerations. It is essential to include the

planner automation on the ground side as it is the primary driver of all surface operations. The ground side and the

air side are two different automation systems that could have different scope, work with different inputs, use

different processing logic, and could even have different kinds of outputs. However, the two systems are expected to

individually satisfy certain requirements such as missed-alert rate and false-alarm rate. To realize the benefits

resulting from having two CD&R systems also requires addressing the discrepancies resulting from having two

CD&R systems.

The following are the objectives of the integrated CD&R system:

1. Ensure the safety of all aircraft and ground vehicles involved in airport surface operations.

2. Realize the airport operational plan created by planning automation tools such as SARDA.

3. Reduce controller workload by reducing false alerts.

4. Reduce controller workload by preventing the escalation of low-probability long-term conflicts into high-

probability short-term conflicts requiring controller attention.

5. Improve the lead time to detection of conflicts by directly exchanging conflict alerts.

It should be noted that the CD&R systems are not primarily tasked with efficiency. It is assumed that the task of

improving the efficiency of surface operations rests with the planner. CD&R helps realize the plans created by

planners such as SARDA and GoSAFE without any conflicts. As such, CD&R is an enabler for realizing the plan

created by SARDA, which if realized as planned is expected to result in efficiency benefits.

The following options are considered for the integrating the tower and flight deck-automation systems in order to

realize the objectives:

1. Explore the options of enhancing the performance of the CD&R systems by exchanging information over a

datalink between the tower automation and flight-deck automation.

2. Develop operational procedures and associated rules to resolve discrepancies between the two CD&R

systems.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


8

IV. Integrated CD&R System Concepts

The integrated CD&R system can be described in terms of the following: (i) information exchanged between the

tower and flight-deck automation systems using the datalink, and (ii) functional requirements on the individual

CD&R sub-systems, individual display/UI sub-systems, and the airport operational planner sub-system. CD&R

integration concepts can be classified into four categories as shown in Table 4, differing in terms of the amount and

the nature of the information that is exchanged over the datalink. Table 5 shows a finer decomposition of these four

categories, resulting from more specific identification of the alert and intent information.

Table 4. Classification of Integrated CD&R System Concepts

Without Intent With Intent

Without Alerts Baseline Integration Concept Option B Integration Concepts

With Alerts Option A Integration Concepts Option C Integration Concepts

Table 5. Finer Decomposition of Integrated CD&R System Concept Options

Without Intent

With Intent

Aircraft Intent +

(Taxi Route + Runway Sequence) Aircraft Intent +

(Taxi Route + RTAs)

Without Alert Baseline B1 B2

With Alert

Tower Conflict Alert Info, No FD CD Logic

A0

Conflict Alert Info A1 C11 C12

Conflict Alert Info + Reconciliation Info

A2 C21 C22

The Baseline Integration Concept represents a “Non-integrated” mode which does not require any datalink-based

information exchange between the air-side and ground-side CD&R automation systems. This concept is further

described in Section A. The Baseline Integration Concept is the easiest to evaluate in a HITL experiment. As the

name suggests it also serves as a baseline for comparing the benefits resulting from other integration concepts.

Option A integration concepts represent an “Alerts Exchanged” mode which only exchanges the alerts generated

by the CD&R systems and no intent. Under this mode there is no nominal exchange of information between the

tower and aircraft. Information is only exchanged in the event of a conflict being detected. Option A concepts are

expected to result in the least bandwidth requirements and are also expected to be easy to evaluate in a HITL

experiment. Section B provides further description of Option A concepts. The one twist in the Option A category is

that Option A0 represents a special case where there is no conflict-detection logic in the flight-deck system, but

rather the flight-deck system includes only some display capability that can relay conflict alerts from the tower

automation system to the pilots.

Option B integration concepts represent an “Intent Exchanged” mode which only exchanges intent and no alerts.

Under this concept there is a continual exchange of intent information irrespective of the occurrence of a conflict.

Intent information can play a crucial part in reducing false alarms on both sides as well as efficiently resolving

conflicts. Option B concepts are expected to require more bandwidth than Option A concepts. However, the

exchange of intent information is expected to play a significant role in preventing the escalation of conflicts. Section

C provides further description of Option B concepts.

Option C integration concepts represent a “Tightly Integrated” mode which involves exchange of both intent and

alerts. Concepts under this category would be a blend of different Option A and Option B concepts. Option C

concepts are further described in Section D.

A. Baseline Integration Concept: Non-integrated

Figure 4 shows a block diagram of the Baseline integration concept. Cyan blocks represent tower automation.

Purple blocks indicate flight-deck automation. ATC stands for Air Traffic Controllers, which in the current context

represents both the ground and local controllers. Green arrows indicate voice-based communications. TCAI and

FCAI stand for Tower Controller Automation Interactions and Flight Crew Automation Interactions, respectively.

The tower automation consists of a planner sub-system, CD&R sub-system, and a display and/or other user interface

(UI). The planner block is a generic representation of some airport operations planner such as SARDA and

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


9

GoSAFE. The flight-deck automation consists of a CD&R sub-system, and a display/UI. Orange blocks represent

the surveillance and navigation systems that are primary drivers of both the automation systems. Baseline integrated

concept involves air and ground automations running separately, with the only information exchange being done

between the ATC and pilot using voice communications. No datalink communication is involved in this concept.

1. Datalink Communication Requirements

Baseline integration concept does not assume any datalink capability between the tower and the flight deck. All

procedural communications are expected to be accomplished using voice-based communications.

2. Automation Functional Requirements

Baseline integration concept also does not require any additional functional requirements on either the tower

automation or the flight deck automation beyond what are already assumed for the individual systems.

Figure 4. Block Diagram of Baseline Integration Concept

B. Option A Integration Concept: Alerts Exchanged (With Alerts, Without Intent)

Figure 5 shows the block diagram of the Option A integration concepts. The blue arrows indicate datalink-based

communications. A new sub-system called Integration Agent (IA) is introduced into both the tower and flight-deck

automation. The IA sub-system actively facilitates the integration endeavor. Under this integration category the two

CD&R automation systems exchange three types of information using the datalink communication: (i) Conflict Info,

(ii) Resolution Info, and (iii) Conflict Reconciliation Info. Conflict Info refers to the basic information regarding a

conflict such as the IDs of the aircraft involved, time to conflict, and location of conflict. Resolution Info refers to

resolution maneuver options such as stopping or slowing down to avoid the conflict. Conflict Reconciliation Info

refers to additional information related to the conflict such as the current states of the two aircraft, and the predicted

states of the two aircraft. As the name suggests this information is used to resolve discrepancies between the tower

and flight-deck automation.

Option A integration concepts could be further classified into sub-levels of integration concepts as follows:

Level 0. At this level, Conflict Info and Resolution Info are communicated from the tower to the flight deck, in

which there is no separate CD&R logic, but simply some display to show the alerts information sent from

the tower automation.

Planner CD&R

Display/UI

CD&R

Display/UI

Airport Surveillance SystemAircraft Navigation, & Surveillance

System

Tower Automation Flight Deck Automation

ATCFlight Crew

Voice-Based Communications

Taxiway Route, Runway, Clearances (Spot

Release, Departure, Runway Crossing, Taxi),

Conflict Info, Resolution Advisory

Clearance Acknowledgement,

Conflict Info, Resolution Action

Con

flic

t In

fo,

Res

olu

tion

In

fo

Rou

te, R

un

way,

Sch

edu

le,

Seq

uen

ce

Con

flic

t In

fo,

Res

olu

tion

In

fo

TCA

I

FCA

I

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


10

Level 1. At this level Conflict Info and Resolution Info are exchanged between the tower and the flight deck.

Level 2. At this level Conflict Info, Resolution Info, and Conflict Reconciliation Info are exchanged between

the tower and the flight deck.

Figure 5. Block Diagram of Option A Integration Concept

Further details of the Option A datalink communication requirements, the corresponding benefits of information

exchange, functional requirements of the tower and flight-deck automation to realize the benefits are discussed in

the following sub-sections.

1. Option A Datalink Communication Requirements

Table 6 provides a detailed list of communication items required for the Option A integration concepts. It also

lists their data type, and the frequency of information exchange, which directly influence the bandwidth

requirements for datalink communications. NA stands for ‘Not Applicable’ indicating the infeasibility of a certain

communication mechanism. In this case the flight deck cannot detect non-conformance conflicts as it has no route or

schedule information.

2. Benefits of Information Exchange

The following benefits are expected out of the exchange of alerts:

a. Conflict Info: Exchanging conflict alerts enhances the situational awareness of the controllers and the flight

crew in case of missed alerts by their respective automation systems.

b. Resolution Info: Exchanging resolution information is expected to facilitate the convergence towards an

efficient and mutually agreeable conflict resolution strategy.

c. Conflict Reconciliation Info: Exchanging conflict reconciliation information is expected to reduce the false

alarm rate on both sides.

Planner CD&R

Display/UI

CD&R

Display/UI

Airport Surveillance SystemAircraft Navigation, & Surveillance System

Tower Automation Flight Deck AutomationATC

Flight Crew


Taxiway Route, Runway, Clearances (Spot Release,

Departure, Runway Crossing, Taxi), Resolution

Advisory

Clearance Acknowledgement, Resolution Action

Con

flic

t In

fo,

Res

olu

tion

In

fo

Rou

te, R

un

way,

Sch

edu

le, S

equ

ence

Con

flic

t In

fo,

Res

olu

tion

In

fo

IAIA

Dat

alin

k C

om

mu

nic

atio

ns

Conflict Info,

Resolution Info

TCA

I

FCA

I

Conflict Info,

Resolution Info

Conflict

Reconciliation Info

Conflict

Reconciliation Info

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


11

Table 6. Datalink-Based Information Exchange Requirements for Option A

Information Type Information Content Data Type Frequency (Tower to

Flight Deck) Frequency (Flight

Deck to Tower)

Level 0*, Level 1, and Level 2 Requirements

Conflict Info

Conflict code Four digit hex

number or string

May be repeated once per conflict update cycle as long as the conflict lasts. Applicable to all conflicts on the airport surface.

May be repeated once per conflict update cycle as long as the conflict lasts. Only applicable to conflicts in which the flight deck is involved.

Conflicting traffic ID String Same as above Same as above

Distance to traffic Double scalar Same as above Same as above

Time to conflict Double scalar Same as above Same as above

Alert code for route non-conformance (wrong

taxiway, wrong runway)

Four digit hex number or string

At least once for every non-conformance. May be repeated until non-conformance conflict resolved

NA

Alert code for a flight not starting on time from the

ramp spot


Same as above NA

Resolution Info

Advisory code for go-around, abort, halt, slow

down, speed up, turn left, turn right, etc.


At least once per conflict. May be repeated until conflict is resolved. Applicable to all conflicts on the airport surface.

At least once per conflict. May be repeated until conflict is resolved. Only applicable to conflicts in which the flight deck is involved.

Conflict resolution responsibility

Separate codes: one for ‘ATC’ and one for

‘Pilot’ Same as above Same as above

Right of way ID of the aircraft that gets the right of way

Same as above Same as above

Level 2 Requirement Only

Conflict Reconciliation Info

Current state of aircraft: flight status, location,

latitude, longitude, altitude, speed, and heading

Array of double

May be repeated once per conflict update cycle as long as the conflict is not reconciled. Applicable to all conflicts on the airport surface.

May be repeated once per conflict update cycle as long as the conflict is not reconciled. Only applicable to conflicts in which the flight deck is involved.

Current state of the traffic: flight status, location,

latitude, longitude, altitude, speed, and heading

Array of double Same as above Same as above

Predicted state of aircraft at time of conflict: flight status, location, latitude, longitude,

altitude, speed, and heading


Predicted state of the traffic at the time of conflict: flight

status, location, latitude, longitude, altitude, speed,

and heading


Code for conflict reconciliation status


Same as above Same as above

* Level 0 information exchange requirements are identical to those of Level 1, except that the last column of the

table does not apply to Level 0 because there is no flight-deck CD&R system for generating alerts.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


12

3. Functional Requirements of Tower Automation

Certain functional requirements are expected of the tower automation sub-systems and the flight-deck

automation sub-systems to realize the benefits outlined above. The following paragraphs describe the functional

requirements of the tower automation sub-systems. It should be noted that these requirements are specific to the

integration exercise. They are in addition to their nominal functional requirements for the planner, CD&R, and

display/UI sub-systems, of which the functional requirements are specified in their individual design documents.

IA:

Monitoring

Tower IA should monitor the alerts generated by the tower CD&R sub-system. (Level 1 and Level

2 requirement)

Tower IA should monitor the output from the airport surveillance system to track the state of

traffic. (Level 1 and Level 2 requirement)

Communication

Tower IA should communicate the alerts generated by the tower CD&R sub-system to the flight

deck IA. (Level 1 and Level 2 requirement)

Tower IA should supply the current and predicted state of the traffic to the flight deck automation

for reconciliation purposes listed below. (Level 2 requirement only)

Reconciliation

Tower IA should seek to resolve the discrepancies in conflict alerts between ground-side CD&R

and flight-deck-side CD&R by verification of the alert information. (Level 1 and Level 2

requirement)

Tower IA should supply the flight deck’s resolution strategies to the tower CD&R for evaluation

of their impact in resolving the conflict. (Level 1 and Level 2 requirement)

Tower IA should seek to resolve the discrepancies in conflict alerts between ground-side CD&R

and flight-deck-side CD&R by comparing both current and predicted states of the conflicting

aircraft. (Level 2 requirement only)

Situational Awareness

Tower IA should supply the conflict alert information received from the flight deck CD&R to the

tower display. Tower IA should label mismatched conflict alerts. (Level 1 and Level 2

requirement)

Tower IA should supply the effectiveness of the flight deck’s resolution strategies to the tower

display. (Level 1 and Level 2 requirement)

Planner:

The planner could update its traffic model by taking into account the planned conflict resolution

maneuvers. (Level 1 and Level 2 requirement)

CD&R:

The tower CD&R system should evaluate the impact of the planned conflict resolution strategies being

contemplated by the conflicting aircraft in resolving the conflict. (Level 1 and Level 2 requirement)

Display/UI:

The tower automation display should display the alerts generated by the flight-deck automation. (Level 1

and Level 2 requirement)

The tower automation display should distinguish between the matched and mismatched alerts. (Level 1 and

Level 2 requirement)

The tower automation display should indicate to the controller the planned resolution strategy of the flight

deck. (Level 1 and Level 2 requirement)

The tower automation display should also indicate to the controller the effectiveness of the flight deck’s

resolution strategy in resolving the conflict. (Level 1 and Level 2 requirement)

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


13

4. Functional Requirements of Flight-Deck Automation

The following paragraphs describe the functional requirements of the flight-deck automation sub-systems. It

should be noted that these requirements are specific to the integration exercise. They are in addition to their nominal

functional requirements which are specified in their individual design documents.

IA:

Monitoring

Flight-deck IA should monitor the alerts generated by the flight-deck CD&R sub-system. (Level 1

and Level 2 requirement)

Flight-deck IA should monitor the aircraft navigation and surveillance systems to track the state of

the ownship and the traffic. (Level 1 and Level 2 requirement)

Communication

Flight-deck IA should communicate the alerts generated by the flight-deck CD&R sub-system to

the tower IA. (Level 1 and Level 2 requirement)

Flight-deck IA should communicate the current and predicted ownship state and traffic states to

the tower IA for reconciliation purposes listed below. (Level 2 requirement only)

Reconciliation

Flight-deck IA should seek to resolve the discrepancies in conflict alerts between flight-deck-side

CD&R and ground-side CD&R by verification of alert information. (Level 1 and Level 2

requirement)

Flight-deck IA should supply the tower resolution advisories to the flight-deck CD&R for

evaluation of their impact in resolving the conflict. (Level 1 and Level 2 requirement)

Flight-deck IA should seek to resolve the discrepancies in conflict alerts between flight-deck-side

CD&R and ground-side CD&R by comparing current and predicted states of the conflicting

aircraft. (Level 2 requirement only)


Flight-deck IA should supply the conflict alert information received from the tower CD&R to the

flight-deck display. Flight-deck IA should label mismatched conflict alerts. (Level 1 and Level 2

requirement)

Flight-deck IA should supply the effectiveness of the tower resolution advisory to the flight-deck

display. (Level 1 and Level 2 requirement)

CD&R:

The flight-deck CD&R system should evaluate the impact of the conflict resolution advisory from the

tower automation in resolving the conflict. (Level 1 and Level 2 requirement)

Display/UI:

The flight-deck automation display should display the alerts generated by the tower automation. (Level 0,

Level 1, and Level 2 requirement)

The flight-deck automation display should distinguish between the matched and mismatched alerts. (Level

1 and Level 2 requirement)

The flight-deck automation display should indicate to the flight crew the controller-advised resolution

strategy. (Level 0, Level 1, and Level 2 requirement)

The flight-deck automation display should also indicate to the flight crew the effectiveness of the tower’s

resolution advisory in resolving the conflict. (Level 0, Level 1, and Level 2 requirement)

C. Option B Integration Concept: Intent Exchanged (With Intent, Without Alerts)

Figure 6 shows a block diagram of the Option B integrated concept. The focus of this integrated concept is to

exchange intent information in both directions between the tower and the flight deck. The Option B integration

concept relies completely on voice-based communications for all clearances as well as reconciliation of alert

discrepancies between the tower automation and the flight-deck automation. It is noted that most discrepancies

happen because of lack of awareness of intent from both sides. It is expected that exchanging intent information

between the tower automation and the flight-deck automation helps resolve conflicts in accordance with the plan

while ensuring safety.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


14

Figure 6. Block Diagram of Option B Integration Concept

Intent information of the flight-deck automation refers to information related to actions such as takeoff, cross,

and go-around. Intent information from the perspective of the tower automation refers to the desired airport

operational plan. Intent info of the tower automation is further classified in terms of (i) Sequence Info, and (ii) Route

Info. Sequence Info refers to the sequence in which aircraft should use an airport resource such as a taxiway

intersection or a runway. Route Info refers to the actual 3D route and also the timing along the 3D route generated

by planners such as SARDA and GoSAFE.

Option B integration concepts could be further classified into sub-levels of integration concepts as follows:

Level 1. At this level Sequence Info is supplied from the tower automation to the flight-deck automation and

aircraft intent info is supplied from flight-deck automation to tower automation.

Level 2. At this level both Sequence Info and Route Info are supplied from the tower automation to the flight-

deck automation. Information supplied from the flight-deck automation to the tower remains the same as

that for Level 1.

Further details of the Option B datalink communication requirements, the corresponding benefits of information

exchange, functional requirements of the tower and flight-deck automation to realize the benefits are discussed in

the following sub-sections.

1. Option B Datalink Communication Requirements

Table 7 provides a detailed list of communication items required for the Option B integration concepts.

2. Benefits of Information Exchange

The following benefits are expected out of the exchange of alerts:

a. Sequence Info: Sequence Info supplied from the tower to flight deck establishes the right of way between

two aircraft in case of conflict. Thus, it can facilitate the two conflicting aircraft in coming up with

consistent conflict resolution actions that are also consistent with the tower automation’s plan.

b. Route Info: The Route Info supplied from the tower to the flight-deck automation facilitates the flight-deck

automation in assisting the flight crew in realizing the tower automation plan. Knowing the routes of other

Planner CD&R

Display/UI

CD&R

Display/UI


Tower Automation Flight Deck Automation

ATCFlight Crew



Departure, Runway Crossing, Taxi), Conflict Info,

Resolution Advisory

Clearance Acknowledgement,


Co

nfl

ict

Info

,

Res

olu

tio

n I

nfo

Rou

te, R

un

wa

y,

Sch

edu

le, S

equ

ence

Co

nfl

ict In

fo,

Res

olu

tio

n I

nfo

IAIA

Sequence Info

Intent to Taxi, Cross,

Takeoff

Da

talin

k

Co

mm

un

icat

ion

s

TCA

I

FCA

I

Route Info

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


15

aircraft also helps reduce the false alarm rate on the flight-deck side and reducing the occurrence of

discrepancies between the tower and the flight-deck automation systems.

c. Aircraft Intent Info: Intent Info supplied from the flight deck to tower can play a significant role in

reducing the false alarm rate on the tower automation side and reducing the occurrence of discrepancies

between the tower and the flight-deck automation systems.

Table 7. Datalink-Based Information Exchange Requirements for Option B

Information Category Information Data Type Frequency (Tower to

Flight Deck) Frequency (Flight

Deck to Tower)

Level 1 and Level 2 Requirements

Sequence Info

Desired crossing sequence at taxiway

intersections

Taxiway node ID, array of aircraft IDs that are expected to cross the taxiway intersection immediately ahead and after the current aircraft

Once for each planning cycle update of the flight. Applicable to all flights using the airport.

NA

Desired usage sequence of runways

Runway ID, array of aircraft IDs that are expected to use the runway immediately ahead and after the current aircraft

Once for each planning cycle update of the flight. Applicable to all flights using the airport.

NA

Aircraft Intent Info

Code for expressing intent to taxi from ramp

spot


NA Once

Code for expressing intent to taxi from a

runway exit


NA Once

Code for expressing intent to cross a

runway, runway ID

Four digit hex number or string,

string NA

Once per each runway crossing

Code for expressing intent to take off,

runway ID

Four digit hex number or string,

string NA

Once for departure flights

Level 2 Requirements Only

Route Info

Taxiway route

Array of node numbers or array of alphanumeric link

labels

Once per each flight NA

RTAs Array of double Once per flight NA

Runway String (e.g., 17R) Once per flight NA

Spot Release Time Scalar double (e.g.,

123550.12) Once per flight NA

Takeoff Time Scalar double Once per flight NA

3. Functional Requirements of Tower Automation

IA:

Monitoring

The tower IA should monitor the planner updates. (Level 1 and Level 2 requirement)

For each taxiing aircraft the tower IA should extract the sequence in which aircraft is expected to

cross an intersection. It should identify the IDs of the aircraft immediately preceding and

immediately succeeding the aircraft of interest. (Level 1 and Level 2 requirement)

For each aircraft the tower IA should identify the sequence in which the aircraft is expected to use

the runway. It should identify the IDs of the aircraft immediately preceding and immediately

succeeding the aircraft of interest. (Level 1 and Level 2 requirement)

Tower IA should access from the planner taxiway routes, and if available Scheduled Times of

Arrival (STAs), and Required Times of Arrival (RTAs) for all flights. (Level 2 requirement only)

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


16

The tower IA should monitor the tower automation user interface for possible inputs from the

controller on the clearances issued and the desired operational plan of the airport. (Level 2

requirement only) Communication

The tower IA should pass on the taxiway usage sequence and the runway usage sequence to the

individual flight deck at an update rate that is the same as that of the planner. (Level 1 and Level 2

requirement)

The tower IA should pass the complete route information including the STAs and RTAs as per

their availability to the flight deck at an update rate that is the same as that of the planner. (Level 2

requirement only)

Reconciliation

The tower IA should pass on the aircraft intent info the tower CD&R sub-system. (Level 1 and



The tower IA should pass on the aircraft intent info and the impact of the aircraft intent in

resolving the conflict to the tower display. (Level 1 and Level 2 requirement)

CD&R:

The tower CD&R should use the intent supplied by the flight deck in its evaluation of possible conflicts.

(Level 1 and Level 2 requirement)

Planner:

The planner could update its traffic model by taking into account the planned aircraft actions such as

Takeoff. (Level 1 and Level 2 requirement)

Display/UI:

The tower display should reflect the intent of the aircraft in providing situational awareness to the

controller. (Level 1 and Level 2 requirement)

The tower display should display any conflicts resulting from evaluation of aircraft intent by the CD&R

sub-system. (Level 1 and Level 2 requirement)

The user interface of the tower display should have the option for the controller to enter his/her intent.

(Level 2 requirement only)

4. Functional Requirements of Flight-Deck Automation

IA:

Monitoring

The flight-deck IA should monitor the onboard navigation system to determine the ownship state

information. (Level 1 and Level 2 requirement)

The flight-deck IA should also monitor the flight-deck user interface for inputs from the flight

crew on their intent. (Level 2 requirement only)

Communication

The flight-deck IA should communicate the intent of the aircraft to taxi, to takeoff, and to cross a

runway to the tower IA. (Level 1 and Level 2 requirement)

Reconciliation

The flight-deck IA should supply the sequence info to the flight-deck CD&R. (Level 1 and Level

2 requirement)


The flight-deck IA should supply the desired sequence info to the flight-deck display. (Level 1 and


CD&R:

The flight-deck CD&R should take into account the desired taxiway and runway usage sequence in

determining conflict resolution actions. (Level 1 and Level 2 requirement)

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


17

The flight-deck CD&R should take into the account the planned route, STA, and RTA information in its

evaluation of conflicts. (Level 2 requirement only)

Display/UI:

The flight-deck display should display the taxiway and runway usage sequence in the event of a conflict.

(Level 1 and Level 2 requirement)

The user interface on the flight deck should have the option for the flight crew to enter their intent. (Level 2

requirement only)

D. Option C Integration Concepts: Tightly Integrated (With Alerts and With Intent)

Option C integration concepts are a mixture of Option A and Option B integration concepts. There are four

levels of Option C integration concepts which are composed as follows:

Level 1. Figure 7 shows a block diagram of the Option C Level 1 integration concept. The information

exchange at this level is a combination of the information exchange in Option A Level 1 and Option B

Level 1.



Level 1.



Level 2.



Level 2.

Figure 7. Block Diagram of Option C Level 1 Integration Concept (C11)

The datalink communication requirements, corresponding benefits, tower automation functional requirements,

and flight-deck automation functional requirements for the Option C concepts are the union of the requirements

from the corresponding Option A and Option B concepts.

Planner CD&R

Display/UI

CD&R

Display/UI



Flight Crew




Resolution Advisory

Clearance Acknowledgement, Conflict Info, Resolution

Action

Con

flic

t In

fo,

Res

olu

tion

In

fo

Rou

te, R

un

way,

Sch

edu

le, S

equ

ence

Con

flic

t In

fo,

Res

olu

tion

In

fo

IAIA

Taxiway, Runway

Sequence


Takeoff

Dat

alin

k C

om

mu

nic

atio

ns

Conflict Info,

Resolution Info

TCA

I

FCA

I

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


18


Figure 9. Block Diagram of Option C Level 3 Integration (C12)

Planner CD&R

Display/UI

CD&R

Display/UI



Flight Crew




Resolution Advisory

Clearance Acknowledgement, Conflict Info, Resolution

Action

Con

flic

t In

fo,

Res

olu

tion

In

fo

Ro

ute

, Ru

nw

ay,

Sch

edu

le, S

equ

ence

Co

nfl

ict In

fo,

Res

olu

tion

In

fo

IAIA

Taxiway, Runway

Sequence


Takeoff

Dat

alin

k C

om

mu

nic

atio

ns

Conflict Info,

Resolution Info

Conflict

Reconciliation Info

TCA

I

FCA

I

Planner CD&R

Display/UI

CD&R

Display/UI



Flight Crew




Con

flic

t In

fo,

Reso

luti

on

In

fo

Rou

te, R

un

way,

Sch

ed

ule

, S

eq

uen

ce

Con

flic

t In

fo,

Reso

luti

on

In

fo

IAIA

Route, RTAs

Da

talin

k C

om

mu

nic

atio

ns

Conflict Info,

Resolution Info

Clearances

Guidance

TCA

I

FCA

I


Takeoff

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


19


V. Illustrative Examples

Sample demonstration scenarios involving the integrated CD&R concept options are discussed in this section.

All these scenarios are based on the DFW airport model. The following are typical scenarios where the benefits of

integration can be expected:

Scenarios where either one or both of the automation systems has a false alarm.

Scenarios where either one or both of the automation systems has a missed alert.

Integrated CD&R for the above items improves the situational awareness of humans and reduce overall missed-

alert rates. In general any CD&R system is expected to have near-zero missed-alert rate; hence, both CD&R systems

are expected to have very low missed-alert rates. However, it is expected that both systems will have false-alarms

due to the limitations of intent information. Table 8 lists the advantages and limitations of the two CD&R systems in

their current form. The following sub-sections describe scenarios where the benefits of an integrated CD&R system

can be observed.

A. Scenario 1: Runway Incursion Conflict

The scenario considered in this experiment involves a runway incursion between the Ownship and traffic on the

runway 18R as shown in Figure 11. The Ownship has just landed on 13R and is attempting to cross the arrival

runway 18R on its way (shown by the white line) to the ramp area. The traffic not seen in this figure lands on the

runway 18R (shown in orange line). The Ownship crosses the runway when the traffic has just landed resulting in a

runway incursion.

Planner CD&R

Display/UI

CD&R

Display/UI



Flight Crew




Co

nfl

ict In

fo,

Res

olu

tio

n I

nfo

Ro

ute

, Ru

nw

ay,

Sch

edu

le, S

equ

ence

Co

nfl

ict In

fo,

Res

olu

tio

n I

nfo

IAIA

Route, RTA,

Taxiway, Runway

Sequence

Intent, Clearance

Acceptance/Rejection

Dat

alin

k C

om

mu

nic

atio

ns

Conflict Info,

Resolution Info

Conflict

Reconciliation Info

Clearances

Guidance

TCA

I

FCA

I

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


20

Table 8. Advantages and Limitations of Ground-Based and Flight-Deck-Based CD&R Systems

Advantages Limitations

Ground-Based CD&R

The tower surveillance can be better than the aircraft surveillance if data-fusion techniques are used to blend ADS-B data with RADAR and multilateration data.

The tower automation does not have complete state and vehicle control information of flights, e.g., acceleration and throttle settings of the aircraft. So, the ground-based conflict detection module cannot reliably determine if an aircraft is ready to take off or not.

The tower automation has the advantage of knowing the taxiway routes of all flights.

Flight-Deck-Based CD&R

Flight-deck automation has very accurate and complete information of itself. Using the throttle setting information, it can detect more reliably its own intent to take off.

Aircraft surveillance can at best be as good as the tower surveillance system.

Flight-deck automation does not have the route information of the traffic. So, the flight-deck-based conflict detection module cannot accurately predict the trajectory of aircraft on taxiways.

Figure 11. Illustration of Scenario 1

The following two sub-sections analyze the above-described with and without the integration of the CD&R

systems.

Without Integration (Baseline)

In the baseline integration setting (described in the previous sub-section), the ground-side conflict detection

system generates two alerts: (i) runway incursion situational alert well before the runway incursion (shown in Figure

12), and (ii) actual runway incursion alert once the ownship starts crossing the runway (shown in Figure 13). The

controller orally communicates the runway incursion information once the Ownship starts crossing the runway

giving little time for the Ownship to stop or the traffic to go around. The controller could avoid this by

communicating the RISA to the Ownship well ahead of the runway incursion. However, this procedure would

increase the workload of the controller as there may be many RISA encounters during the day. Table 9 shows the

human and automation situational awareness of the conflict without any integration.

Ownship

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


21

Figure 12. Runway Incursion Situation Alert on Tower Display, Scenario 1

Figure 13. Runway Incursion Alert, Scenario 1

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


22

Table 9. Situational Awareness without Integration, Scenario 1

Human/Automation Situation Understanding

Human Controller RISA & RI Alert

Ownship Pilot Normal situation till runway incursion happens. Controller's orally communicated information once runway incursion is detected by the ground-side CD&R.

Traffic Pilot Normal situation till runway incursion happens. Controller's orally communicated information once runway incursion is detected by the ground-side CD&R.

Automation Tower RISA & RI Alert

Ownship None

Traffic None

With Integration

Scenario 1 with Integration Option A0 can be described as follows.

Datalink communication is expected between the tower and the Ownship.

The Ownship flight deck has an electronic moving map display.

No flight-deck conflict detection automation is assumed for either the ownship or the traffic.

Alerts generated on the ground side are communicated to the Ownship over the datalink.

In the integrated approach, the RISA alerts are directly communicated to the flight deck to prevent the runway

incursions from happening. Figure 14 shows the flight-deck display with RISA alert on the electronic moving map

display. The RISA alert cautions the pilot 45 s ahead of the runway incursion, preventing the runway incursion

unless the Ownship pilot disregards the RISA. Communicating RISAs over the datalink improves the situational

awareness of the aircraft not equipped with ADS-B (In) and a flight-deck CD&R system, and most importantly

effectively prevents runway incursions from happening without increasing the workload of the controller. Table 10

shows the situational awareness of the humans and automation involved in this scenario.

Figure 14. Flight Deck Display under A0 Integration Concept, Scenario 1

Point of RISA Alert

Ownship

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


23

Table 10. Situational Awareness under A0 Integration Concept, Scenario 1


Human

Controller RISA

Ownship Pilot RISA

Traffic Pilot Normal Situation

Automation

Tower RISA

Ownship RISA

Traffic NA

B. Scenario 2: Runway Incursion Conflict

Scenario 2 also involves a runway incursion false-alarm involving the Ownship and the traffic. The Ownship is a

departure waiting to take off from runway 17R while the traffic crosses the runway in front of the Ownship. It is

assumed that the controller issued a taxi-into-position-and-hold clearance for the Ownship and a runway crossing

clearance for the traffic. The runway incursion detection criterion for this scenario is as follows:

“If aircraft1 is on the runway and moving, and aircraft2 is crossing the same runway in the path of aircraft1, then

runway incursion”

Table 11 splits the above runway-incursion criterion into sub-criteria and correspondingly lists the reliability of

evaluating those criteria.

Table 11. Reliability of Evaluating Runway Incursion Criteria

Runway Incursion Sub-Criterion Reliability of Evaluation

Given the surveillance position data of aircraft1 determining if it is on the runway.

The runway spans a large geographical area compared to the surveillance position errors. Therefore, this criterion can be reliably evaluated by the ground-side CD&R.

Given the surveillance velocity data determining if the aircraft1 is moving.

This is a challenging problem because when an aircraft starts moving from a state of rest its speed is very low and comparable to the accuracy of the surveillance velocity errors. Therefore, this could lead to frequent false alarms.

Given the surveillance position data of aircraft2 determining if it is on the runway crossing.

The runway crossing also spans a large geographical area compared to the surveillance position errors. Therefore, this criterion can be reliably evaluated by the ground-side CD&R.

Given the surveillance velocity data of aircraft2 determining if it is moving.

Whereas detecting if an aircraft is moving when it is stationary is very challenging, it is easier when the aircraft is actually moving with speeds that are higher than the surveillance accuracy. Therefore, if the aircraft were actually crossing the runway, it could be detected reliably.


In the baseline case where there is no integration, the ground-side CD&R rightly generates a RISA (as shown in

Figure 15) the moment the traffic aircraft crosses the ramp spot heading towards the runway crossing. However,

once the Ownship is on the runway and the traffic starts crossing, it conservatively elevates the conflict to a runway

incursion as seen in Figure 16. Table 12 describes the situational awareness of the humans and automation systems

involved in this scenario in the absence of any integration.

With Integration

Scenario 2 with Integration Option B1 can be described as follows.


The Ownship flight-deck has an electronic moving map display.

The Ownship flight-deck has ATCAM CD&R automation.

The Ownship broadcasts its auto-throttle engagement status and throttle setting as part of its intent to

takeoff.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


24

Figure 15. RISA Generated by the Ground-Side CD&R

Figure 16. Runway Incursion False-Alarm Generated by Ground-Side CD&R

Ownship

Traffic

Ownship

Traffic

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


25



Human

Controller RISA & RI Alert

Ownship Pilot Normal Situation / Traffic Alert


Automation

Tower RISA & Possible RI Alert

Ownship Normal Situation / Traffic Alert

Traffic NA

An integration agent with the following logic is built on the ground-side automation.

“If auto-throttle engagement status = ‘false’ and throttle setting less than takeoff throttle setting, then aircraft1 not

ready to depart, hence no runway incursion”

With the above integration agent logic implemented and the aircraft1 broadcasting its intent (auto-throttle

engagement status and throttle setting) the performance of the ground-side CD&R improves. Figure 17 shows the

same situation where the Ownship is on the runway and the traffic is crossing the runway that caused a runway

incursion alert without integration. In this case the situation remains in a RISA as opposed to a runway incursion.

Table 13 shows the improved situational awareness resulting from the integration efforts.

Figure 17. With Integration the Conflict Remains RISA, Scenario

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


26

Table 13. Situational Awareness under B1 Integration Concept, Scenario 2


Human

Controller RISA

Ownship Pilot Normal Situation/Traffic Alert


Automation

Tower RISA

Ownship Normal Situation/Traffic Alert

Traffic NA

C. Scenario 3: Taxiway Head-On Collision

Scenario 3 involves a false-alarm resulting from taxiway aircraft. The Ownship is crossing runway 18R as shown

in Figure 18* and encounters traffic in the opposite direction in close proximity. As mentioned in Table 8, the flight-

deck CD&R does not have the route information for the traffic (as such information is not inherently available on

the flight deck; and transmission of such information from the tower is within the scope of the integrated concepts).

In the absence of route information, the collision conflict detection is based on dead-reckoning assumptions which

could lead to false-alarms as is the case in the current scenario.

Figure 18. Illustration of Scenario 3

* The use of ATCAM’s display graphics here is solely for illustration purposes, and it does not reflect on the

capabilities of ATCAM.

Ownship Traffic

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


27


Figure 19 shows the collision alert generated by the flight-deck CD&R. In the absence of intent information of

the traffic the Ownship assumes the traffic will head straight and generates a collision conflict alert. Table 14

describes the situational awareness of the human and automation in this situation.

Figure 19. Head-On Conflict Alert from Flight-Deck CD&R, Scenario 3


Human/Automation Conflict Understanding

Human

Controller Normal Situation

Ownship Pilot Collision Conflict

Traffic Pilot False Collision Conflict Alarm

Automation

Tower Normal Situation

Ownship Collision Conflict

Traffic Collision Conflict

With Integration

Scenario 3 with Integration Option B1 can be described as follows.


The Ownship flight-deck has an electronic moving map display.

The Ownship flight-deck has ATCAM CD&R automation.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


28

The tower broadcasts the route information for all flights.

In this case the Ownship has the route information for the traffic. Therefore, the flight-deck-based conflict

detection algorithm could make trajectory predictions using the route information. For the current study, however,

adding such trajectory prediction capability on the flight-deck automation would require modification of NASA’s

ATCAM software, which was beyond the intended scope of the study; hence this approach was not adopted. Instead

of making changes to the ATCAM software, OSI has elected to display the conflict detected by ATCAM on the

FARGO EMM display as shown in Figure 20. Along with the conflict, the route of the traffic is also drawn as a

solid brown line. The route information together with the predicted location of collision is expected to provide the

Ownship pilot the necessary situational understanding. Table 15 illustrates the improved situational awareness

resulting from the integration.

Figure 20. EMM Display for the Integrated Scenario

Table 15. Situational Awareness with Integration, Scenario 3


Human

Controller Normal Situation

Ownship Pilot Normal Situation


Automation

Tower Normal Situation

Ownship Normal Situation / Traffic Alert

Traffic Normal Situation / Traffic Alert

D. Scenario 4: Taxiway Collision

Whereas the previous two scenarios involved false-alarms, the current scenario involves a real taxiway collision

conflict. Figure 21 illustrates the scenario where the two aircraft highlighted in yellow circles are bound for a

collision at the intersection.

Conflict Alert Point

Traffic Route

Ownship

Traffic

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


29

Figure 21. Scenario 4, Taxiway Collision Conflict


In this case both the ground-side conflict detection system and the flight-deck-side conflict detection system

detect the conflict. However, the two conflict detection systems do not detect the conflict at the same time, which is

not a problem when the two conflict detection systems are not integrated. The ground-side conflict detection system

detects the conflict almost 55 s ahead of the conflict. The flight-deck-side conflict detection system detects the

conflict 22 s ahead of the conflict. Table 16 shows the situational awareness of the humans and automation systems

involved in this conflict.



Human

Controller Normal Situation till tconflict - 55; Collision conflict from tconflict - 55 to tconflict

Ownship Pilot Normal Situation till tconflict - 22; Collision conflict from tconflict - 22 to tconflict

Traffic Pilot Normal situation till controllers verbally alerts pilot; taxiway collision conflict upon visual acquisition of the Ownship

Automation

Tower Normal Situation till tconflict - 55; Collision conflict from tconflict - 55 to tconflict

Ownship Normal Situation till tconflict - 22; Collision conflict from tconflict - 22 to tconflict

Traffic No automation assumed

With Integration

Scenario 4 with Integration Option A1 can be described as follows.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


30


The Ownship flight-deck transmits its conflict alerts to the Tower.

The Tower conflict detection system transmits its conflict alerts to the Tower.

Integration does not change the way the individual conflict detection systems respond to the conflict. However,

duration the times (tconflict-55) and (tconflict-22) there is discrepancy in the integrated system where only the ground-

side detects the conflict. Table 17 shows the situational awareness of the humans and automation systems involved

in this conflict.



Human

Controller Normal Situation till tconflict - 55; Collision conflict from tconflict - 55 to tconflict

Ownship Pilot Normal Situation till tconflict - 55; Potential conflict from tconflict-55 to tconflict-22; Collision conflict from tconflict - 22 to tconflict

Traffic Pilot Normal situation till controllers verbally alerts pilot; taxiway collision conflict upon visual acquisition of the Ownship

Automation

Tower Normal Situation till tconflict - 55; Collision conflict from tconflict - 55 to tconflict

Ownship Normal Situation till tconflict - 55; Potential conflict from tconflict-55 to tconflict-22; Collision conflict from tconflict - 22 to tconflict

Traffic No automation assumed

In this research it is assumed that both the ground-side and flight-deck-side conflict detection systems have very

low missed alert rate. Therefore, it can be expected that in most conflict circumstances both the conflict detection

results will detect the conflict. However, depending upon conflict probing horizon parameter the different conflict

detection systems could detect the conflict at different times. In this case the ground-side uses a probing horizon of

60 s and the flight-deck-side say uses a probing horizon of 30 s. Then, it can be expected that the flight-deck-side

cannot detect a conflict sooner than 30 s. Therefore, the mismatched conflict alerts could last for 30 s.

VI. Concluding Remarks

With ground-side and air-side conflict detection and resolution (CD&R) technologies being developed for

surface operations as part of the Next-Generation Air Transportation System (NextGen), this paper investigates the

various options for integrating these separately developed technologies with the hope of realizing synergistic

benefits not otherwise achievable from either system. The integration concepts hinge on the use of datalink

communications to exchange information between the two systems.

Various integration concepts are identified to align with progressive communications, navigation, and

surveillance (CNS) technologies and other NextGen automation technologies through a number of anticipated

timeframes. The development effort systematically considers the use of datalink communications for exchange of

information relevant to CD&R, including alert information and intent information, to arrive at a number of

integration concepts. System architectures for realization of these concepts are defined, together with high-level

functional requirements for developing such systems.

A simulation environment has been developed to demonstrate the operational capacities of these integration

concept options. This environment makes use of simulation and CD&R software which include ground-side

components developed by the authors’ research team and air-side components developed by NASA. Illustrative

examples to demonstrate how the integrated CD&R concepts would improve safety and situation awareness have

been provided.

Acknowledgments

This research has been performed under NASA support from Ames Research Center. The authors thank the

following individuals for valuable feedback and suggestions: Ms. Sandy Lozito, Dr. Yoon Jung, Dr. Waqar Malik,

Dr. Gautam Gupta, Ms. Denise Jones, Mr. Glover Barker, and Mr. Seth Kurasaki.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


31

References 1NTSB, “The National Transportation Safety Board is investigating a wing tip clipping that occurred between an

Airbus A380 (F-HPJD) and a Bombardier CRJ-700 (N641CA) at John F. Kennedy Airport in New York last night,”

NTSB Press Release, Office of Public Affairs, National Transportation Safety Board, April 12, 2011.

(http://www.ntsb.gov/news/2011/110412.html) 2“FAA’s NextGen Implementation Plan,” Federal Aviation Administration, Dept. of Transportation,

Washington, DC, June 2008. 3“Concept of Operations for the Next Generation Air Transportation System,” Version 2.0, Joint Planning and

Development Office, June 13, 2007. 4Cheng, V. H. L., Vaddi, V. V. S. S., and Sweriduk, G. D., “Concept and Requirements for Airport Surface Conflict

Detection and Resolution,” Report Submitted Under NASA NRA NNA10DE59C, Report Date January 14,

2011. 5Cheng, V. H. L., Vaddi, V. V. S. S., and Sweriduk, G. D., “Surface Conflict Detection and Resolution with

Emphasis on Trajectory Based Operations,” Base Year Final Report Submitted Under NASA NRA

NNA10DE59C, Report Date June 24, 2011. 6Jung, Y. C., Hoang, T., Montoya, J., Gupta, G., Malik, W., and Toibas, L., “A Concept and Implementation of

Optimized Operations of Airport Surface Traffic,” Proceedings of the 2010 AIAA Aviation, Technology,

Integration and Operations Conference, September, 2010. 7Malik, W., Gupta, G., and Jung, Y. C., “Managing Departure Airport Release for Efficient Airport Surface

Operations,” Proceedings of the 2010 AIAA Guidance, Navigation, Control Conference and Exhibit, August,

2010. 8Gupta, G., Malik, W., and Jung, Y. C., “A Mixed Integer Linear Program for Airport Departure Scheduling,”

Proceedings of the 2009 AIAA Aviation, Technology, Integration and Operations Conference, September,

2009. 9Gupta, G., Malik, W., and Jung, Y. C., “Incorporating Active Runway Crossings in Airport Departure Scheduling,”

Proceedings of the 2010 AIAA Guidance, Navigation, Control Conference and Exhibit, August, 2010. 10

Rathinam, S., Montoya, J., and Jung, Y. C., “An Optimization Model for Reducing Aircraft Taxi Times at the

Dallas Fort Worth International Airport,” Proceedings of the 2008 AIAA Aviation, Technology, Integration

and Operations Conference, September, 2008. 11

Rathinam, S., J. Montoya, and Y. Jung, “Algorithms for Scheduling and Routing of Aircraft at Airports,” NASA

Airspace Systems Program Technical Interchange Meeting, Austin, TX, March 18–20, 2008. 12

Wei, W., J. Tsao, L. Martin, J. Poage, V. Cheng, A. Seo, and D. David, “Integrated Approaches for Surface Traffic

Optimization in the Presence of Uncertainties,” NASA Airspace Systems Program Technical Interchange

Meeting, Austin, TX, March 18–20, 2008. 13

Cheng, V. H. L., “Collaborative Automation Systems for Enhancing Airport Surface Traffic Efficiency and

Safety,” Proceedings of the 21st Digital Avionics Systems Conference, Irvine, CA, October 27–31, 2002. 14

Cheng, V. H. L., “Airport Surface Operation Collaborative Automation Concept,” Proceedings of the AIAA

Guidance, Navigation, and Control Conference, Austin, TX, August 11–14, 2003, AIAA Paper 2003-5773. 15

Cheng, V. H. L., “Surface Operation Automation Research for Airport Tower and Flight Deck Automation,” Proc.

2004 IEEE Intelligent Transportation Systems (2004 ITSC), Washington, DC, October 3–5, 2004, Paper

TuC2.4. 16

Cheng, V. H. L., “Collaborative Automation Systems for Enhancing Airport Surface Traffic Efficiency and

Safety,” Proceedings of the 21st Digital Avionics Systems Conference, Irvine, CA, October 27–31, 2002.

17Cheng, V. H. L., Crawford, L. S., Lam, T., and Sweriduk, G. D, “Navigation and Situational Awareness for

Landing and Runway Crossing, Ground-Operation Situational Awareness and Flow Efficiency (GO-SAFE),”

Final Report Prepared Under NASA SBIR Contract No. NAS2-9905, June, 2001. 18

Cheng, V. H. L., “Research Progress on an Automation Concept for Surface Operation with Time Based

Trajectories,” 7th Integrated Communications, Navigation, and Surveillance (ICNS) Conference, Herndon,

VA, May 1–3, 2007. 19

Cheng, V. H. L., and D. C. Foyle, “Automation Tools for Enhancing Ground-Operation Situation Awareness and

Flow Efficiency,” Proceedings of the AIAA Guidance, Navigation, and Control Conference, Monterey, CA,

August 5–8, 2002, AIAA Paper 2002-4856. 20

Cheng, V. H. L., V. Sharma, and D. C. Foyle, “Study of Aircraft Taxi Performance for Enhancing Airport Surface

Traffic Control,” IEEE Transactions on Intelligent Transportation Systems, Vol. 2, No. 2, pp. 39–54, June

2001.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


32

21Sweriduk, G. D., V. H. L. Cheng, A. D. Andre, and D. C. Foyle, “Automation Tools for High-Precision Taxiing,”

Proc. 26th Digital Avionics Systems Conference, Dallas, TX, October 21–25, 2007. 22

Cheng, V. H. L., G. D. Sweriduk, C. H. Yeh, A. D. Andre, and D. C. Foyle, “Flight-Deck Automation for

Collaborative Surface Operation Concept,” Proc. AIAA Guidance, Navigation, and Control Conf., Honolulu,

HI, August 18–21, 2008. 23

Dorighi, N. S., and B. T. Sullivan, “FutureFlight Central: A Revolutionary Air Traffic Control Tower Simulation

Facility,” Proc. AIAA Modeling and Simulation Technologies Conference, Austin, TX, 2003, Paper AIAA-

2003-5598. 24

Cheng, S. Y., V. H. L. Cheng, Y. G. Seo, L. H. Martin, S. A. Verma, and D. S. Ballinger, “Ground Operation

Concept Testing Requirements and Challenges,” Proc. AIAA Modeling and Simulation Technologies

Conference, Hilton Head, SC, August 20–23, 2007, Paper AIAA-2007-6701. 25

Martin, L., S. Verma, D. Ballinger, and V. Cheng, “Developing a Decision Support Interface for Surface Domain

Air Traffic Controllers,” Proc. Human Factors and Ergonomics Society’s 51st Annual Meeting, Baltimore,

MD, October 1–5, 2007. 26

Verma, S., T. Kozon, V. Cheng, and D. Ballinger, “Changes in Roles/Responsibilities of Air Traffic Control under

Precision Taxiing,” Proc. 26th

Digital Avionics Systems Conference, Dallas, TX, October 21–25, 2007. 27

Airport Surface Detection Equipment—Model X (ASDE-X), NAS Subsystem Level Specification, Version 1.1,

Federal Aviation Administration, Washington DC, May 24, 2001. 28

Scardina, J., “Overview of the FAA ADS-B Link Decision,” Office of System Architecture and Investment

Analysis, Federal Aviation Administration, June 7, 2002. 29

Capezzutto, V., Olster, D., Curry, M., and Pendergast, S. L., “Runway Incursion Reduction Program Surveillance

System, NASA/FAA Atlanta Demonstration,” Proceedings of 17th Digital Avionics Conference, 1998. 30

Ianiello, J. W., and Kruczek, R. M., “Airport Surface Collision Warning System Implementation,” Proceedings of

the Vehicle Navigation and Information Systems Conference, 1993. 31

Eggert, J. R., B. R. Howes, M. Picardi Kuffner, H. Wilhelmsen, and D. J. Bernays, “Operational Evaluation of

Runway Status Lights,” Lincoln Laboratory Journal, Vol. 16, No. 1, 2003 32

Anon, “Runway Incursion Alerting System,” Information Brochure by QinetiQ. 33

Meier, C., J. Jakobi, P. Adamson, S. Lozito, and L. Martin, “Benefits of Advanced Surface Movement Guidance

and Control Systems (A-SMGCS),” ATC Quarterly, Vol. 13, No. 4, pp. 329–356, 2006. 34

Smeltink, J. W., M. J. Soomer, P. R. de Waal, and R. D. van der Mei, “An Optimisation Model for Airport Taxi

Scheduling,” Technical Report, National Aerospace Laboratory NLR, June 11, 2004. 35

“Operational Requirements Document (ORD-Update),” Document No. D1.3.5, Version No. 1.0, European Airport

Movement Management by A-SMGCS (EMMA), April 25, 2006. 36

Moller, M., “EMMA Air-Ground Operational Service and Environmental Description (OSED-update),” Document

No. D1.3.1.u, Version No. 1.0, European Airport Movement Management by A-SMGCS (EMMA), April 25,

2006. 37

Jakobi, J., “A-SMGCS Services, Procedures, and Operational Requirements (SPOR): A Preliminary Concept and

Framework for Validation Activities in EMMA2,” Document No. 2-D1.1.1, Version No. 1.0, European

Airport Movement Management by A-SMGCS (EMMA), December 2, 2008. 38

Vaddi, S., Sweriduk, G. D., Kwan, K., Lin, V., Nguyen, J., and Cheng, V. H. L., “Concept and Requirements for

Airport Surface Conflict Detection and Resolution,” Proceedings of the 2011 ATIO Conference, September,

2011. 39

Vaddi, S., Kwan, J., Fong, A., and Cheng, V. H. L., “Deterministic and Probabilistic Conflict Detection

Algorithms for Airport Surface Operations,” Proceedings of the 2012 AIAA Guidance, Navigation, Control

Conference and Exhibit, August, 2012. 40

Pledgie, S., B. Gallet, Y. Zhao and D. Wu, “4D Surface Trajectory Synthesis,” NASA Airspace Systems Program

Technical Interchange Meeting, San Antonio, TX, October 13–16, 2009. 41

Atkins, S., and C. Brinton, “Concept Description and Development Plan for the Surface Management System,”

Journal of Air Traffic Control, 2002. 42

Atkins, S., Y. Jung, C. Brinton, S. Stell, and S. Rogowski, “Surface Management System Field Trial Results,”

Proceedings of the AIAA 4th Aviation Technology, Integration and Operations (ATIO) Forum, Chicago, IL,

September 20–22, 2004, Paper AIAA 2004-6241. 43

Brinton, C. R., S. C. Atkins, and A. Hall, “Analysis of Taxi Conformance Monitoring Algorithms and

Performance,” 7th Integrated Communications, Navigation, and Surveillance (ICNS) Conference, Herndon,

VA, May 1–3, 2007.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645


33

44Foyle, D. C., A. D. Andre, R. S. McCann, E. M. Wenzel, D. R. Begault, and V. Battiste, “Taxiway Navigation and

Situation Awareness (T-NASA) System: Problem, Design Philosophy, and Description of an Integrated

Display Suite for Low-Visibility Airport Surface Operations,” SAE Transactions: Journal of Aerospace, 105,

pp. 1411–1418, 1996. 45

McCann, R. S., D. C. Foyle, B. L. Hooey, A. D. Andre, B. Parke, and B. Kanki, “An Evaluation of the Taxiway

Navigation and Situation Awareness (T-NASA) System in High-Fidelity Simulation,” SAE Transactions:

Journal of Aerospace, Vol. 107 , 1612–1625, 1998. 46

Jones, D., “Runway Incursion Prevention System – Demonstration and Testing at the Dallas/Fort Worth

International Airport,” Proc. 20th Digital Avionics Systems Conference, Daytona Beach, FL, 2001. 47

Young, S. D., and D. R. Jones, “Runway Incursion Prevention: A Technology Solution,” Joint Meeting of the

Flight Safety Foundation’s 54th

Annual International Air Safety Seminar, the International Federation of

Airworthiness’ 31st International Conference, and the International Air Transport Association, Athens,

Greece, November 5–8, 2001. 48

Jones, D. R., “Collision Avoidance for Airport Traffic (CAAT),” NASA Airspace Systems Program Technical

Interchange Meeting, Austin, TX, March 18–20, 2008. 49

Green, D F., Otero, S. D., Barker, G. D., and Jones, D. R., “Initial Concept for Terminal Area Conflict Detection,

Alerting, and Resolution Capability On or Near the Airport Surface,” NASA/TM-2009-215696. 50

Jones, D. R., and Prinzel, L. J., “Simulator Evaluation of Runway Incursion Prevention Technology for General

Aviation Operations,” NASA/TP–2011-217045. 51

Jones, D. R., Prinzel, L. J., Otero, S. D., and Barker, G. D., “Collision Avoidance for Airport Traffic Concept

Evaluation,” Proceedings of the 28th Digital Avionics Systems Conference, October 3-7, 2009.

52Jones, D. R., Prinzel, L. J., Shelton, K. J., Bailey, R. E., Otero, S. D., and Barker, G. D., “Collision Avoidance for

Airport Traffic Simulation Evaluation,” Proceedings of the 29th Digital Avionics Systems Conference,

October 3-7, 2010.

Dow

nloa

ded

by U

NIV

ER

SIT

Y O

F C

AL

IFO

RN

IA -

BE

RK

EL

EY

on

June

25,

201

4 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

012-

5645

air-ground integrated concept for surface conflict ... · the next-generation air transportation...

Documents