October 2013

NASA/TM–2013-218052

Initial Concept for Terminal Area Conflict 

Detection, Alerting, and Resolution Capability 

On or Near the Airport Surface, Version 2.0

Sharon D. Otero and Glover D. Barker

Lockheed Martin Mission Services, Hampton, Virginia

Denise R. Jones

Langley Research Center, Hampton, Virginia
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 Aeronautics and 

Space Administration

Langley Research Center 

Hampton, Virginia 23681-2199

October 2013

NASA/TM–2013-218052

Initial Concept for Terminal Area Conflict 

Detection, Alerting, and Resolution Capability 

On or Near the Airport Surface, Version 2.0

Sharon D. Otero and Glover D. Barker

Lockheed Martin Mission Services, Hampton, Virginia

Denise R. Jones

Langley Research Center, Hampton, Virginia
Available from: 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 

443-757-5802 

The use of trademarks or names of manufacturers in this report is for accurate reporting and does not 

constitute an official endorsement, either expressed or implied, of such products or manufacturers by the 

National Aeronautics and Space Administration. 
 Begin your report below this instruction. Press F1 or Help for more. 

Table of Contents 

Abstract ........................................................................................................................................... 1

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

2 Background ................................................................................................................................. 2

2.1 Runway Incursions............................................................................................................... 2

2.2 Low Altitude Air-to-Air Conflicts ....................................................................................... 3

2.3 Taxi Conflicts....................................................................................................................... 4

2.4 ATCAM Concept ................................................................................................................. 4

3 ATCAM Concept Description .................................................................................................... 4

3.1 Alert Definitions .................................................................................................................. 5

3.2 Indication Definitions .......................................................................................................... 7

3.3 Runway Safety Monitor (RSM) ........................................................................................... 8

3.4 Low Altitude Conflict Monitor (LACM) ............................................................................. 9

3.5 Taxi Conflict Monitor (TCM) ............................................................................................ 11

4 ATCAM Data Communications ............................................................................................... 12

4.1 Ownship Data..................................................................................................................... 13

4.2 Traffic Data ........................................................................................................................ 13

4.3 Output Data ........................................................................................................................ 13

5 Technical Description of ATCAM Algorithms ........................................................................ 14

5.1 Integration of Algorithms .................................................................................................. 14

5.2 Algorithm Performance ..................................................................................................... 14

5.3 Aircraft Reference Positions .............................................................................................. 15

5.4 RSM ................................................................................................................................... 15

5.5 LACM ................................................................................................................................ 18

5.6 TCM ................................................................................................................................... 19

6 Initial Description of ATCAM Resolution Advisories ............................................................. 23

6.1 Resolution Advisories ........................................................................................................ 23

6.2 RSM RAs ........................................................................................................................... 23

6.3 LACM RAs ........................................................................................................................ 26

6.4 TCM RAs ........................................................................................................................... 28

6.5 Pilot Reaction Delays ......................................................................................................... 29

7 Summary ................................................................................................................................... 30

References ..................................................................................................................................... 31

Appendix A – RSM Operational States ........................................................................................ 35

Appendix B – RSM Scenarios and Alert Criteria ......................................................................... 38

Appendix C – RSM Scenarios and SURF IA Indication Criteria ................................................. 48

Appendix D – Flight Data Requirements...................................................................................... 50

Appendix E – Surveillance Discussion ......................................................................................... 52

E.1 Surveillance Performance .................................................................................................. 52

E.2 Intent Data ......................................................................................................................... 53

E.3 ADS-B Altitude Data ........................................................................................................ 54

i
Acronyms 

ADS-B Automatic Dependent Surveillance - Broadcast 

AGL Above Ground Level 

AMASS Airport Movement Area Safety System 

ASDE-X Airport Surface Detection Equipment – Model X 

A-SMGCS Advanced Surface Movement Guidance and Control Systems 

ATC Air Traffic Control 

ATCAM Airport Traffic Collision Avoidance Monitor 

ATMA Airport Terminal Maneuvering Area 

CAAT Collision Avoidance for Airport Traffic 

CD&R Conflict Detection & Resolution 

CG Center of Gravity 

ConOps Concept of Operations 

CPA Closest Point of Approach 

CPDLC Controller-Pilot Data Link Communications 

EPR Engine Pressure Ratio 

EUROCAE European Organization for Civil Aviation Equipment 

FAA Federal Aviation Administration 

FAROS Final Approach and Runway Occupancy Signal 

GA General Aviation 

GPS Global Positioning System 

ICAO International Civil Aviation Organization 

JPDO Joint Planning and Development Office 

LACM Low Altitude Conflict Monitor 

LAHSO Land and Hold Short Operations 

MSL Mean Sea Level 

NA Not Applicable 

NAS National Airspace System 

NASA National Aeronautics and Space Administration 

NextGen Next Generation Air Transportation System 

NPRM Notice of Proposed Rulemaking 

NTSB National Transportation Safety Board 

ORD Chicago-O’Hare International Airport

RA Resolution Advisory 

RAAS Runway Awareness and Advisory System 

RI Runway Incursion 

RIPS Runway Incursion Prevention System 

RSI Runway Status Indication 

RSM Runway Safety Monitor 

RTCA Radio Technical Commission for Aeronautics 

RWSL Runway Status Lights 

SPR Safety, Performance, and Interoperability Requirements 

SURF IA Surface Indications and Alerts 

TCAS Traffic Alert and Collision Avoidance System 

TCM Taxi Conflict Monitor 

TI Traffic Indication 

TIS-B Traffic Information Service-Broadcast 

4-D 4-Dimensional

ii
Abstract 

The Next Generation Air Transportation System (NextGen) concept for 2025 envisions the movement 

of large numbers of people and goods in a safe, efficient, and reliable manner. The NextGen will remove 

many of the constraints in the current air transportation system, support a wider range of operations, and 

deliver an overall system capacity up to 3 times that of current operating levels. In order to achieve the 

NextGen vision, research is necessary in the areas of surface traffic optimization, maximum runway 

capacity, reduced runway occupancy time, simultaneous single runway operations, and terminal area 

conflict prevention, among others. 

The National Aeronautics and Space Administration (NASA) is conducting Collision Avoidance for 

Airport Traffic (CAAT) research to develop technologies, data, and guidelines to enable Conflict 

Detection and Resolution (CD&R) in the Airport Terminal Maneuvering Area (ATMA) under current and 

emerging NextGen operating concepts. The term ATMA was created to reflect the fact that the CD&R 

concept area of operation is focused near the airport within the terminal maneuvering area. In the 

following, an initial concept for an aircraft-based method for CD&R in the ATMA is presented. This 

method is based upon previous NASA work in CD&R for runway incursion prevention, the Runway 

Incursion Prevention System (RIPS). 

1 Introduction 

By 2025, U.S. air traffic is predicted to increase significantly, yet the current air traffic management 

system may not be able to accommodate this growth. In response to this challenge, a consortium of 

industry, academia, and government agencies have proposed a revolutionary new concept for U.S. 

aviation operations, termed the Next Generation Air Transportation System or “NextGen” [JPDO, 2004]. 

Emerging NextGen operational concepts represent a different approach to air traffic management and as a 

result, a dramatic shift in the tasks, roles, and responsibilities for the flight deck to ensure a safe, 

sustainable air transportation system. 

To support the operational goals – the “vision” – of NextGen, the Joint Planning and Development 

Office (JPDO) has published a Concept of Operations (ConOps) [JPDO, 2010] and a research and 

development plan [JPDO, 2007] to develop the technologies that it considers vital to reach the NextGen 

goals. While this vision is not necessarily shared by all nor is it the only way to achieve NextGen, it does 

illustrate many of the challenges to achieving a NextGen operating environment. In this report, the term 

Airport Terminal Maneuvering Area (ATMA) was created to reflect the fact that the CD&R concept area 

of operation is focused near the airport within the terminal maneuvering area. In particular, key 

challenges associated with the NextGen ATMA include: 

• Trajectory-based operations that use closely spaced arrivals and departures to enable airport safety 

and capacity, independent of the visibility and weather conditions. 

• Arrival and departure procedures that shift away from rigid, clearance-based air traffic control 

processes to flexible, adaptive air traffic management principles utilizing reduced spacing buffers, 

more runways, and innovative merging and spacing 4-dimensional (4-D) trajectory operations. 

• Automated surface management systems that utilize dynamic algorithms to calculate the most 

efficient movement of all surface traffic to increase efficiency [Cheng et al., 2003]. Pilots will be 

required to comply with 4-D taxi clearances, dictating that aircraft arrive at specific locations 

within specific time windows. 

• Potential pilot responsibility for “separation” from other aircraft, during all phases of flight, 

regardless of visibility conditions. 

1
Proactive safety layers are being designed to enable these emerging NextGen operational concepts. 

Automation to manage, assist, and even conduct these procedures and operations will be developed. 

Nonetheless, it is imperative to have a conflict detection system that is an integral part of and integrated 

with, the emerging NextGen technologies to provide an additional protective layer should these proactive 

measures unforeseeably fail. This critical need is recognized under the JPDO vision in its research and 

development plan [JPDO, 2007]. 

This paper presents a concept for an aircraft-based method for CD&R in the ATMA. A concept and 

technical description is given for CD&R algorithms that detect potential conflicts in the ATMA during 

runway, taxiway, and low altitude operations and generate indications and alerts and possibly resolution 

advisories for display to the pilot. Note that in this paper, a conflict is defined as a condition that can lead 

to a collision if no avoidance action is taken. This version updates previously published work [Green et 

al., 2009] with the revisions summarized in the document revision history. 

2 Background 

Relevant research and systems for CD&R in the ATMA are discussed. 

2.1 Runway Incursions 

The harmonized Federal Aviation Administration (FAA)/International Civil Aviation Organization 

(ICAO) definition for runway incursion [FAA, 2009a], adopted on October 1, 2007, is: 

Any occurrence at an aerodrome involving the incorrect presence of an aircraft, vehicle, or person on 

the protected area of a surface designated for the landing and take-off of aircraft. 

Runway incursions are a serious aviation safety hazard. The National Transportation Safety Board 

continues to have improving runway safety on its most wanted list of transportation safety improvements 

for aviation [NTSB, 2011]. The FAA is committed to reducing the severity, number, and rate of runway 

incursions by implementing a combination of guidance, education, outreach, training, technology, 

infrastructure, and risk identification and mitigation initiatives [FAA, 2011]. Progress has been made in 

reducing the number of serious incursions – from a high of 67 in Fiscal Year (FY) 2000 to 6 in FY 2010. 

However, the rate of all incursions has risen steadily over recent years – from a rate of 12.3 incursions per 

million operations in FY 2005 to a rate of 18.9 incursions per million operations in FY 2010. [FAA, 2011 

and FAA, 2009a] The worst aviation accident – 583 fatalities – was caused by a runway incursion in 

1977 when two fully loaded 747 airplanes collided on a runway at Tenerife airport. The accident 

occurred in low visibility (300 meters visual range) conditions. A departing aircraft crashed head-on into 

an aircraft taxiing in the opposite direction on the same runway. The present-day statistics and events are 

cause enough for alarm but, without proactive counter-measures, the increase in air traffic forecasted 

under NextGen could potentially result in catastrophic increases in runway incursion accidents. 

Numerous efforts have been launched by the FAA, industry, and others to reduce the frequency of 

runway incursions and the risk of runway collisions to meet the recommendations put forth by the NTSB 

[NTSB, 2000]. These solutions include Airport Surface Detection Equipment Model X (ASDE-X), 

Airport Movement Area Safety System (AMASS); Final Approach Runway Occupancy Signal (FAROS); 

Runway Status Lights (RWSL); enhanced controller training; airport surface operations advisory 

circulars; improved airport markings and lighting; improved pilot education, training, and awareness; and 

revised pilot/controller communications phraseology. These efforts target improved awareness and 

enhanced surveillance, but do not include technology solutions for the flight deck.

2
Currently, no system is available (either ground or aircraft-based) that directly provides the flight 

deck with alerts of potential runway conflicts with other traffic. However, some flight deck-based ATMA 

situation awareness systems are available, including: 

• Honeywell International Inc. has developed an aircraft-based Runway Awareness and Advisory 

System (RAAS) [Honeywell, 2006]. RAAS uses Global Positioning System (GPS) position data 

and a database to provide aural–only advisories that supplement flight crew awareness of own 

aircraft position during ground operations and on approach to landing. RAAS does not, however, 

provide alerts of runway incursion conflicts with other traffic. 

• SafeRouteTM, developed by Aviation Communication & Surveillance Systems, provides the pilot 

with an electronic map of the airport surface on an electronic flight bag, showing ownship and 

other aircraft positions. The system will also indicate when a runway is occupied by highlighting 

the runway on the display [Evans, 2007]. SafeRouteTM does not, however, detect and alert for 

conflicts between aircraft and vehicles. 

NASA- and FAA-sponsored research has also been conducted by Honeywell Aerospace and Sensis 

Corp. to transmit ASDE-X runway incursion alerts (which are optimized for Air Traffic Control (ATC)) 

to the flight deck [Hughes, 2007]. Additional research is needed to determine the effectiveness of 

providing the ATC-optimized ASDE-X alerts to the flight crew and data link requirements. 

Working cooperatively with NASA, Era Corporation has developed a conflict detection and alerting 

system, known as PathProxTM, that detects potential runway conflicts and generates alerts for display to 

the flight crew [Cassell et al., 2003]. PathProxTM does not include the cockpit display device and is not 

commercially available at this time. 

Under NASA’s Aviation Safety Program, Synthetic Vision Systems Project, the Runway Incursion 

Prevention System (RIPS) was developed to address the growing problem of runway incursions as a 

significant contributor to the fatal aviation accident rate in commercial, business, and general aviation 

sectors [Jones et al., 2001, Jones, 2002, Jones, 2005, and Jones and Prinzel, 2006]. As part of this work, 

the Runway Safety Monitor (RSM) was conceived as a method of automated CD&R for approach, 

landing, and surface (runway) operations. This effort focused on flight deck technologies and alerting, in 

contrast to other agency and company initiatives. 

The Enhanced Traffic Situational Awareness on the Airport Surface with Indications and Alerts 

(SURF IA) application has been established by RTCA Special Committee 186 to reduce the likelihood 

and severity of runway incursions and collisions. Safety, performance, and interoperability requirements 

(SPR) [RTCA, 2010b] have been developed under SURF IA to increase flight crew situation awareness of 

the runway environment and facilitate an appropriate and timely response to potential conflict situations. 

As part of this effort, the FAA sponsored flight demonstrations, conducted by Aviation Communication 

and Surveillance System and Honeywell, to show the feasibility of implementing this technology. NASA 

also conducted research that was integrated into this effort. 

2.2 Low Altitude Air-to-Air Conflicts

In today’s operations, the most notable airborne method of flight deck-based CD&R is provided by 

the Traffic Alert and Collision Avoidance System (TCAS). TCAS predicts a penetration to an aircraft’s 

airspace and provides associated alerts to the flight crew. TCAS has been developed and improved for 

over 25 years and has been very effective in reducing or eliminating airborne collisions. This system does 

have known limitations in the vicinity of airports and TCAS alerts are inhibited at low altitudes. 

Resolution Advisories are not issued below 1000 feet Above Ground Level (AGL) and audible Traffic 

Advisories are not issued below 500 feet AGL [FAA, 2000]. Research to date indicates that the use of 

TCAS may work for envisioned trajectory-based 4-D operations [Ivanescu et al., 2004], but the suitability 

of TCAS degrades in operations nearing the airport [Pritchett et al., 1995]. 

3
RTCA SC-147, Traffic Alert and Collision Avoidance System, is addressing how to make TCAS II 

more compatible within the National Airspace System and how to integrate ADS-B into the next 

Collision Avoidance System [RTCA, 2010a]. In the area of collision avoidance, RTCA SC-147 is 

specifically chartered to: 

 make collision avoidance more compatible with routine operations in congested airspace, 

including busy terminal areas in the National Airspace System (NAS), now and out through the 

2025 time frame; 

 make appropriate use of ADS-B information in a future collision avoidance system (or nextCAS); and 

 reduce the radio frequency congestion at 1090 MHz. 

Since international harmonization of CAS equipment is essential, SC-147 will work collaboratively with 

EUROCAE Working Group 75 (WG75) and appropriate ICAO bodies. Many experts in ADS-B 

technology, a potentially important component of a future CAS, already support RTCA through Special 

Committee 186. Recommendations on the development of future collision avoidance systems are slated 

for delivery by September 2011 [RTCA, 2010]. 

2.3 Taxi Conflicts 

The NextGen concept proposes the use of ground-based automation to schedule surface traffic and 

generate 4-D taxi clearances to enable precise departure times and limited simultaneous runway 

occupancy [JPDO, 2010]. This move toward 4-D surface operations pushes the CD&R need beyond the 

runway and must include surface operations. Research has been initiated to determine the information 

display requirements for presentation of automated 4-D taxi clearances to the pilot and the ability of the 

pilot to comply with the 4-D clearances [Williams et al., 2006, Foyle et al., 2009, Prinzel et al., 2009, 

Shelton et al., 2009, Cheng et al., 2009, and Foyle et al., 2011]. The safety impact of following 4-D taxi 

clearances has not been determined, however; it is a concern that the pilot may be so focused on 

following 4-D clearances to meet scheduled arrival times that unintentional taxi conflicts could result. If 

this is the case, taxi conflict detection capability becomes critical. 

2.4 ATCAM Concept 

For emerging NextGen operating concepts, CD&R capabilities are desirable as the last of several 

proactive safety-enabling separation assurance layers. To provide a basis for this development and to 

begin research under CAAT, an initial concept for CD&R in the ATMA is proposed in the following as 

an extension of the RIPS work. This concept – Airport Traffic Collision Avoidance Monitor (ATCAM) –

is described in the following sections. Also, the data communications to support this application are 

described to assess the feasibility of the concept, given current and projected equipage and current and 

NextGen operating environments. 

3 ATCAM Concept Description 

The goal of ATCAM is to detect potential traffic conflicts in the ATMA and generate flight deckbased indications, alerts, and possibly resolution advisories to provide sufficient awareness so that 

collisions are avoided. ATCAM operates at low altitudes near the airport without conflicting with TCAS, 

as well as on the runway and during taxi operations for multiple classes and equipage of aircraft and 

surface vehicles. 

ATCAM is comprised of three separate aircraft-based algorithms that rely on target state information 

that can be obtained from various sources: 

4
1. The Runway Safety Monitor (RSM) is designed to detect runway incursion conflicts and generate 

alerts and indications that provide the flight crew with sufficient awareness to take action to avoid a 

collision. RSM was developed in support of RIPS research and is retained as a core element of ATMA 

CD&R. Enhancements are planned for RSM based on current and emerging NextGen operational 

concepts and research findings. 

2. The Low Altitude Conflict Monitor (LACM) is designed to detect and alert for air-to-air conflicts 

at low altitudes near the airport. Indications are not currently generated for LACM. 

3. The Taxi Conflict Monitor (TCM) is designed to detect and alert for ground taxi conflicts 

anywhere in the airport movement and ramp areas. Indications are not currently generated for TCM. 

The three algorithms are separate and independent but are integrated and share data to increase the 

probability of detection for all possible conflicts during airport operations. RSM has been through 

extensive simulation and flight testing. LACM and TCM are less mature but have been evaluated in 

simulation studies. Results of those studies suggest further refinements to these algorithms. 

Figure 1 is a high level flow chart depicting the process for ATCAM conflict detection including 

coordination and prioritization of indications and alerts in the event of multiple indications and alerts 

from the same or multiple algorithms. A description of this process follows. 

When the ownship is on the surface or at low altitude and new traffic data becomes available (see 

Section 4.0, ATCAM Data Communications Requirements), the RSM algorithm runs first to monitor 

other airborne or ground traffic for possible runway incursions. After RSM completes, either the LACM 

algorithm or the TCM algorithm is called depending on the position of the ownship. If the ownship is on 

the ground, TCM monitors possible conflicts with other aircraft or vehicles anywhere on the airport 

surface. If the ownship is airborne, LACM monitors possible conflicts with other airborne aircraft. 

It is possible for conflicts detected by TCM or LACM to overlap with RSM (i.e., a TCM/LACM 

conflict could also be a runway incursion) and conflicts can also occur that are not runway incursions. 

ATCAM resolves any differences between alerts issued by the algorithms and prioritizes the alert data for 

output. The alert data, or null data if no alerts, is then output for use by the flight deck aural and graphical 

displays (see Section 4.3, Output Data Requirements). 

This process of reading the ownship and traffic data, calling the conflict detection algorithms, 

coordinating and prioritizing indications and alerts, then outputting the indication and alert data is 

repeated approximately once per second. All algorithms are enabled by default but can be individually 

disabled. Each algorithm is implemented using the concept and technical approach that is optimal for the 

type of conflict being monitored. 

A high level description of the indication and alerting concept and algorithms is given in the 

following sections. The ATCAM concept will be updated as necessary to address new or different (based 

on test and evaluation) CAAT requirements and concepts for NextGen. 

3.1 Alert Definitions 

The SURF IA SPR has adopted the definition of alerts [FAA, 2009] as follows: Alerts refer to flight 

deck annunciations meant to attract the attention of, and identify to the flight crew a non-normal 

operational or airplane system condition. Cautions and warnings are examples of alerts. Caution alerts 

are generated for conditions that require immediate flight crew awareness and subsequent flight crew 

response. An auditory signal and the yellow/amber color are associated with cautions. Warning alerts are 

generated for conditions that require immediate flight crew awareness and immediate flight crew 

response. An auditory signal and the red color are associated with warnings. 

The criteria and thresholds used for the ATCAM alerts are defined in Sections 5.4, 5.5, and 5.6. 

5
Figure 1. ATCAM High Level Flow Diagram 

Conflict(s)

Detected?

Coordinate & 

Prioritize

Indication/Alert

Data

Yes

No Null 

Indication/Alert 

Data

No

Run TCM

Yes

ATCAM Main

Run LACM

Output 

Indication/Alert 

Data For 

Displays

No

Ownship 

Airborne?

Yes

Get Ownship 

Data

New Traffic

Data AND

Ownship On

Ground or

Low Altitude?

Run RSM

6
The alert terminology used by ATCAM is as follows: 

3.1.1 Caution Alert

A caution alert provides immediate awareness of other traffic that may cause an unsafe or a hazardous 

situation. In the initial design, cautions are issued by LACM and TCM for low altitude and taxi 

operations and by RSM for runway incursions during approach or when holding in position on the 

runway. The feasibility and appropriateness of generating caution alerts for these types of operations will 

be determined based on test and evaluation. Avoidance maneuvers are not required and resolution 

instructions are not given when a caution is issued. In some cases, appropriate action may be advisable at 

the pilot’s discretion to prevent the condition from progressing to a more serious situation. For example, 

when a caution is issued for taxi operations, avoidance action such as slowing down or stopping may be 

done to prevent the situation from progressing to the point a warning alert is warranted. 

3.1.2 Warning Alert

A warning alert indicates there is a high probability of collision or near collision with other traffic 

and, therefore, avoidance maneuvering should be initiated. The specific maneuver taken (e.g., go-around, 

abort takeoff, stop taxi, etc.) is at the pilot’s discretion. Warnings are issued by RSM, LACM and TCM 

using criteria and thresholds that are algorithm specific. The criteria and thresholds will be refined based 

on test and evaluation. 

3.1.3 Resolution Advisories (RA)

RAs are intended to provide the pilot direction on the maneuver to take to safely avoid a collision. 

RAs are issued in the current version of ATCAM, in prototype form. Further research is required, and 

currently in progress, to determine the feasibility of providing RAs in conjunction with warning alerts to 

effectively resolve conflict situations without producing undesired consequences. For example, what 

avoidance maneuvers should be taken without creating secondary conflicts with other traffic? Section 

6.0, Initial Requirements for ATCAM Resolution Advisories, describes current RA research. 

3.2 Indication Definitions 

In addition to alerts, the SURF IA SPR has also adopted the definition of indications [RTCA, 2010b], 

as follows: Indications identify to the flight crew a normal operational condition that could become a 

runway safety hazard. Indications do not actively attract attention from flight crews but provide enhanced 

situation relevant information to facilitate flight crew perception of safety hazards. Indications are not 

alerts. 

Only the RSM algorithm currently implements indications (as defined in the SURF IA SPR [RTCA, 

2010b]), for potential runway conflicts. Neither LACM nor TCM implement indications for low altitude 

or taxi scenarios. 

3.2.1 Traffic Indication (TI)

Traffic indication (TI) highlights a potential runway traffic collision/hazard that may emerge in the 

near future. TIs are intended to increase the flight crews’ awareness of relevant traffic that could affect 

runway safety. If appropriately cleared, the flight crew proceeds with the intended operation. 

3.2.2 Runway Status Indication (RSI)

Runway Status Indication (RSI) identifies if the runway that own-ship is approaching or using is inuse or occupied by other traffic. Before proceeding, the crew should ensure they have the appropriate 

clearance and the indicated traffic is not a factor. Note: The absence of an RSI does not alleviate pilots 

from verifying the runway status prior to proceeding. 

7
3.3 Runway Safety Monitor (RSM) 

RSM monitors data for the ownship aircraft and other aircraft or vehicles and predicts potential 

incursions/collisions and notifies the flight crew to avoid a possible incursion/collision. Testing has 

included single runway, intersecting runways and intersecting flight path scenarios during both simulation 

and flight [Green, 2006, Jones, 2002 and 2005, Jones et al., 2001, and Jones and Prinzel, 2006]. In some 

scenarios, RSM detects a runway incursion early and issues an alert before the situation degenerates into a 

severe incursion. In other scenarios, RSM predicts the incursion before it occurs and alerts the pilot early 

to avoid the incursion. RSM also detects runway conflicts that are not part of the strict definition of 

runway incursion, such as when both aircraft are airborne in the process of landing in the approach phase 

and/or taking off in the climb out phase. RSM is generic for both general aviation (GA) and large 

commercial air carrier operations, and for any ownship aircraft type. The most recent version of RSM is 

described in detail in [Green, 2006]. 

A major concept of RSM is the use of runway incursion (RI) zones. A RI zone is a three-dimensional 

virtual zone that overlays a runway and the approach area. A detailed description of the RI zone 

placement is given in Section 5.4.2. A two-dimensional plan view of the RI zones at the Wallops Flight 

Facility is shown in Figure 2. RSM monitors for conflicts/incursions only when the ownship is inside a 

RI zone and traffic is inside or approaching the same zone as the ownship or in an intersecting zone. 

Figure 2. Runway Incursion Zones at Wallops Flight Facility 

Another major RSM concept is the use of operational states for the ownship and traffic. Seven 

operational states or flight phases are defined: taxi, pre-takeoff, takeoff roll, climb-out, approach, rollout 

and fly-thru. These states are described in Appendix A. Combinations of these states between the 

8
ownship and traffic, positions inside the RI zones, and other criteria determine whether or not an 

indication or alert will be issued. More detail is provided in Section 5.4 and Appendices A, B, and C. 

CD&R under the RIPS concept includes aural and visual displays in the flight deck. For instance, an 

airport map display depicting a warning alert for a runway incursion from a simulation at the Chicago 

(ORD) airport is shown in Figure 3. 

Figure 3. Airport Map Display showing Warning Alert for a Runway Incursion 

3.4 Low Altitude Conflict Monitor (LACM) 

The intent of the LACM algorithm is to monitor conflicts that can occur at low altitudes near the 

airport including conflicts that may not be detected by RSM. As shown in Figure 1 above, LACM is run 

in addition to RSM. LACM provides conflict detection coverage at altitudes below 1000 feet. The 

implementation of LACM does not utilize aircraft operational state information and RI zones as does 

RSM. Instead, the algorithm’s initial design is based on many of the same concepts that are used in the 

current operational version of TCAS II [FAA, 2000]. However, there are a number of significant 

differences between LACM and TCAS in the way traffic data is obtained, the methods of computation, 

the criteria and thresholds used for alerting, and the types of alerts that are issued (see Section 5.5). Some 

of the TCAS terminology is also used by LACM such as Closest Point of Approach (CPA), time to CPA 

(called range tau) and time to co-altitude (called vertical tau). The technical approach for LACM is to 

compute closing speed, range tau, vertical tau and other data between ownship and an approaching 

aircraft to determine if specific criteria and thresholds are met for issuing alerts. The alerts and 

methodologies used by LACM are designed to achieve the same high level of performance as TCAS and 

are described in Section 5.5. 

Figure 4 gives examples of LACM caution and warning alerts at the ORD airport. In Figure 4a, the 

ownship has departed a runway. The traffic has departed a parallel runway and is turning on a path to 

cross in front of ownship. LACM detects this potential conflict and initially issues a caution (indicated by 

9
yellow icons). As the scenario progresses, the aircraft continue toward a potential collision point and 

LACM issues a warning (indicated by red icons), as shown in Figure 4b. 

4a. LACM Caution Alert 

4b. LACM Warning Alert 

Figure 4. LACM Alerts. 

10
3.5 Taxi Conflict Monitor (TCM) 

The TCM algorithm is designed to improve safety on the airport surface by monitoring for conditions 

that cause conflicts and collisions during taxi operations for multiple classes of aircraft as well as surface 

vehicles. The algorithm’s design uses an approach similar to LACM by computing distances between 

aircraft, closing speeds, time to closest point of approach (range tau) and other parameters used for alert 

criteria. The obvious difference from LACM is that all aircraft, vehicles, etc., on the airport surface can 

be very close to each other while moving or not moving. 

The close proximity of aircraft and vehicles to one another on the surface requires very strict accuracy 

tolerances. These tolerances, as well as all alert criteria and thresholds for TCM, are described in Section 

5.6. Some of the parameters used by LACM (e.g., vertical speed, altitude, vertical tau, etc.) are not 

required by TCM. However, based on developmental testing, additional alert criteria are required by 

TCM because of the higher probability of nuisance alerts (see Section 5.2). All alert criteria and 

thresholds are described in Section 5.6. Because TCM is based on the LACM and the TCAS concept, the 

algorithm does not use a detailed database of airport taxiways, runways and ramps. 

The feasibility of utilizing traffic’s ATC clearances, specifically, assigned taxi route and hold short 

instructions, as a factor in taxi conflict detection and alerting is being investigated. Knowledge of the 

traffic’s intent on the surface combined with the current state information could result in delayed alerting 

and reduced nuisance alerts. A detailed database of the airport including taxiways and ramp areas would 

be required in this instance. Future versions of TCM may utilize this information if determined to be a 

feasible approach. 

Figure 5 gives examples of TCM caution and warning alerts. In Figure 5a, the taxiing traffic and 

ownship are approaching the same intersection as ownship exits the runway after landing. TCM detects 

this potential conflict, and initially issues a caution (indicated by yellow icons). In Figure 5b, as the 

aircraft continue to converge, TCM issues a warning (indicated by red icons). 

5a. TCM Caution Alert 

11
5b. TCM Warning Alert 

Figure 5. TCM Alerts between commercial aircraft. 

4 ATCAM Data Communications 

The ICAO defined operational requirements for Advanced Surface Movement Guidance and Control 

Systems (A-SMGCS) are to achieve safe, orderly and expeditious movement of aircraft and vehicles at 

airports under all visibility conditions, traffic densities, and airport layouts. These standards were 

proposed by ICAO to ensure safety and standardization with respect to global interoperability [ICAO, 

1997]. NASA and its industry partners developed a prototype A-SMGCS architecture and operational 

concept that was initially designed to improve operational capability. This operational concept and 

system design have been tested in both full-mission simulation and operational flight test experiments at 

major airport facilities. The data structure developed for the first implementation of an aircraft-based ASMGCS, demonstrated at the Atlanta Hartsfield International Airport in 1997 [Jones and Young, 1998], 

coupled with the enhanced design to provide runway incursion detection and alerting demonstrated at 

Dallas-Fort Worth International Airport in 2000 [Jones et al., 2001] were used as the basis for the current 

data parameters for ATCAM. 

ATCAM data communications is handled by a separate software program that accesses data from 

various sources available on the aircraft and provides the data to ATCAM. Flight and traffic data are 

obtained from available sources and converted and processed into the format required by ATCAM. This 

method of data communications has been utilized successfully in past RIPS research and has proven to be 

highly reliable and effective during flight tests and simulations. A significant advantage of this method is 

that ATCAM does not have to perform data communications functions. Appendix D lists the current data 

parameters used by ATCAM. 

Appendix E contains a discussion on surveillance performance and intent data as it relates to ATMA 

CD&R. 

12
4.1 Ownship Data 

The ownship data used by the ATCAM software is obtained from the aircraft systems and consists of 

the data described in Appendix D, as available. Additional parameters may be required with future 

development of the ATCAM software. 

4.2 Traffic Data 

Data for airport traffic can be obtained from several different sources, such as: 

 Traffic Information Service-Broadcast (TIS-B) comprised of traffic information from surface 

surveillance radar and multi-lateration [RTCA, 2007], 

 Automatic Dependent Surveillance-Broadcast (ADS-B) [RTCA, 2002], 

 TCAS [FAA, 2000], and 

 GPS-based surface vehicle location tracking system such as Era Corporation’s Squid [Era, 2008]. 

Appendix D contains a list of the traffic data parameters currently used by ATCAM. 

For CAAT, the data communications software accesses traffic data from any available source. If any 

of the parameters are not available from the data source in use, they are marked accordingly, so that 

ATCAM does not attempt to use any spurious values. Unavailable parameters may be computed 

independently, or may be subject to data smoothing, described below. ADS-B Out deployment has been 

mandated and is expected to be the primary source for future NextGen requirements. However, current 

Mode-S/Mode-C TCAS data (range, bearing and relative altitude) will continue to be used as well as 

other new sources from on-board sensors and ground systems. Since ATCAM does not utilize range, 

bearing and relative altitude, TCAS data must be converted to lat/long and altitude mean sea level (MSL) 

by the communications program for use by ATCAM. Currently, ATCAM accesses data once per second, 

regardless of the rate at which the data was received. 

When traffic parameters are not reported or not up to date, an estimate of the current value(s) must be 

computed by the algorithms based on the last known value(s). This process, known as data smoothing, 

involves computations that decrease in accuracy with increasing time between updates. Computation 

accuracy is further decreased if data rates for specific values are different and the exact times since the 

last update are uncertain (for example, the position update is one hertz but the ground speed is updated at 

two or three hertz and the exact update times are unknown). 

4.3 Output Data 

ATCAM output parameters provide information on the generated alert or indication and conflict 

traffic to enable display of the alert or indication to the flight crew or ATC. The specific output 

parameters for the alert or indication are based on the aural and graphical flight deck alerting display 

requirements. The current ATCAM output parameters, listed below, were defined for RSM alerts. 

Additional parameters are available in RSM and can be provided in future upgrades as required. Other 

output parameters derived from LACM and TCM alerting display requirements will also be added as 

required. 

 Traffic ID (e.g., ICAO aircraft address) 

 Alert code 

 Distance to traffic (range) 

 Distance to collision point 

 Time (sec) to collision point 

 Time (sec) to closest point of approach (range tau) 

 Traffic bearing relative to ownship 

 Traffic relative altitude 

13
 RA maneuver, if provided (RSM or TCM) 

Or

 Horizontal, vertical and acceleration maneuver & navigation pairs (LACM) 

The alert code is a single four digit hex number that compresses information including type of alert or 

indication (i.e., caution or warning, TI or RSI), the name of the traffic’s runway and the traffic’s 

departure/arrival status (for example, a warning for traffic departing runway 25). The efficient encoding 

and decoding routines used to generate the alert code are generic for any airport and compatible with the 

ATC two-way Controller-Pilot Data Link Communications (CPDLC) protocols defined in references 

[ICAO, 1999] and [RTCA, 1993]. A benefit of being compatible with CPDLC is the alert information 

can be data linked to ATC for display on a controller’s workstation as well as be presented aurally, 

visually or both to the pilot. 

When an alert is given, an RA directive may be provided to the pilot. For RSM, a runway maneuver 

may be directed, such as go around. For TCM, a taxi maneuver such as slow down may be directed. For 

LACM, however, a horizontal, vertical, acceleration or a combination of these maneuvers and 

corresponding navigation may be directed. Examples of this include climb 300 ft/min (vertical), bear left 

30 degrees (horizontal) or reduce speed (acceleration). A more detailed discussion of RAs is located in 

Section 6, Initial Description of ATCAM Resolution Advisories. 

5 Technical Description of ATCAM Algorithms 

The previous section described data communications and parameters for the ATCAM algorithms. 

This section provides a technical description for each of the three algorithms. The first three subsections 

on integration of algorithms, performance, and aircraft reference positions are applicable to all three 

algorithms. Finally, algorithm-specific details are presented. 

5.1 Integration of Algorithms 

Because there is overlap in the coverage of component algorithms in ATCAM, the algorithms are 

integrated to share data and insure that consistent and accurate alerts are issued. The LACM algorithm is 

integrated with the RSM algorithm to detect any air-to-air conflicts that RSM does not alert for when the 

conflict does not meet incursion criteria. The TCM algorithm is also integrated with RSM because 

ground taxi conflicts can also be runway incursions if the conflict occurs on or near a runway. Integration 

between LACM and TCM is not necessary since there is no overlap between the algorithms’ operational 

domains. 

The integration of LACM and TCM with RSM is implemented by sharing and coordinating alert 

output data. Since LACM and TCM run after RSM (see Figure 1) and have access to RSM data, 

information is known about ownship and traffic operational states and RSM alert status. This information 

is used to coordinate the alert data that is output for aural and graphical display in the cockpit. For 

example, when air-to-air conflicts are also runway incursions, the ownship and traffic runway status 

information from RSM can be issued in addition to the low altitude alert data. Due to design differences, 

there are cases when alert criteria will be met by only one algorithm or one algorithm may detect a 

conflict earlier than the other. This redundancy in conflict monitoring significantly improves overall 

performance. 

5.2 Algorithm Performance 

The algorithms can be evaluated based on the timeliness of indications and alerts and missed, false, 

and nuisance indication and alert rates. The timeliness of an alert is determined by whether a caution is 

14
issued with sufficient time to provide adequate traffic situation awareness prior to a potential hazardous 

situation, or whether a warning is issued with sufficient time for the pilot to take action and safely avoid a 

collision. The definition of missed, false, and nuisance alerts are taken from RTCA 2010b. A missed 

alert is a condition where an alert is needed but not provided, including non-equipped vehicles and 

aircraft. For example, a runway incursion or near collision occurs and a warning is not issued, or aircraft 

come close enough to meet the caution minimum separation threshold but the caution is not issued. A 

false alert is an incorrect or spurious alert caused by a failure of the alerting system including the sensor. 

The false alert rate is composed of ownship avionics failures, undetected ownship avionics errors, map 

integrity, and undetected traffic avionics failures. A nuisance alert is generated by a system that is 

functioning as designed but which is inappropriate or unnecessary for the particular condition. The 

nuisance alert rate is composed of position integrity, ownship accuracy, traffic accuracy, and map 

accuracy. A false or nuisance alert could cause an avoidance maneuver that is not necessary and could 

possibly cause secondary conflicts or unnecessary delays. 

The algorithms are being designed to completely eliminate collisions/near collisions in the airport 

area. To accomplish this goal, performance results should be near zero missed and untimely alerts. 

Analyses are required to determine acceptable missed, nuisance, and false alert rates and desired 

probability of detection. Some analyses have been conducted by RTCA SC-186 WG1 subcommittee for 

runway conflicts [RTCA, 2010b]. 

Performance objectives for RSM have been tested in previous flight tests and piloted simulations. 

The most recent RSM flight test at the Wallops Flight Facility resulted in a success rate of no missed or 

late alerts and only one nuisance alert for all incursion scenarios tested [Green, 2006]. Initial simulation 

evaluations of LACM and TCM have been conducted [Jones et al., 2009 and Jones et al., 2010]. 

Enhancements have been made to LACM and TCM based on these evaluations and are reflected in this 

document. 

5.3 Aircraft Reference Positions 

ATCAM uses the latitude and longitude reported for ownship and traffic as the navigation reference 

point for the aircraft (or vehicles). This reference point is the aircraft center of gravity. To determine 

distance between aircraft, ATCAM measures the distance between the exteriors of the aircraft, not the 

distance between reference points. To determine whether an aircraft is in a runway incursion zone, 

ATCAM considers whether any exterior point of the aircraft is in the zone, not just the reference point. 

ATCAM determines the aircraft exterior points by considering the aircraft type (B-757, DC-7, etc.) and 

using the dimensions for that aircraft type (body length, wing span, distance to nose, and distance to tail). 

If the aircraft type is unknown, ATCAM uses a default type of a large aircraft (B-747) to allow a 

conservative estimate. 

5.4 RSM 

5.4.1 Airport Databases

RSM does not require detailed terrain or airport databases that include taxiways, ramps, buildings, 

etc. However, RSM does require highly accurate information for all runways on the airport to include 

latitude and longitude of thresholds and displaced thresholds, runway length and width, length of run-up 

areas, runway true heading, ILS glide slope angle if applicable, runway touchdown aim points, and 

distance from threshold to land-and-hold-short positions on the runway. The existence of intersecting 

runways and intersecting arrival/departure flight paths is determined from the airport diagram. Required 

information is available from publically-available sources. 

5.4.2 Runway Incursion Zone Placement

Accurate placement of RI zones is critical for correct performance of the algorithm and prevention of 

missed and nuisance alerts. The coordinates for the sides and ends of each zone are computed based on 

15
runway information in the airport configuration file and vary for each runway. The sides of the zones 

along the runways are set to be at or just inside the hold short positions if they are known. If runway hold 

short position data are not available, the sides of zones are placed 200 feet from the runway edges. 

The sides of the zones are extended by a look-ahead distance, if an aircraft outside the zone is taxiing 

toward the zone. The look-ahead distance is based on the distance the aircraft requires to stop, given its 

current ground speed and assuming a standard deceleration rate that is not aircraft type specific. If the 

distance between the aircraft and the zone edge is less than the look-ahead distance, the aircraft is 

considered to be inside the zone. This approach allows RSM to issue alerts in time for the aircraft to stop 

before entering the zone. 

The ends of zones will vary based on the intersection of the ILS glide slope path with the RI zone 

altitude. The example below (Figure 6) shows that with a typical zone altitude of 800 feet and a typical 

glide slope angle of 3 degrees, the end of the zone would be calculated to extend approximately 15,265 

feet prior to the touchdown aim-point. (The touchdown aim-point is abeam the ILS glideslope antenna.) 

Assuming the touchdown aim-point is located 1,000 feet from the end of the runway, the zone would 

extend approximately 14,265 feet, or 2.34 nm, prior to the runway threshold. 

Figure 6. Example Using 3-Degree Glide Slope to Determine Incursion Zone Ends 

The width of extended RI zones is greater at the approach ends than at the runway thresholds as 

shown in Figure 2. Greater detail is shown in Figure 7, in plan view, with the extended zone shaded gray. 

The angle at which the extended zone flares, or increases, is determined by the maximum ILS localizer 

deviation, up to a two-dot deviation. For each dot of ILS error, the zone perimeter is 175 feet from the 

centerline at the runway threshold, as modeled by [Parrish et al., 2006]. The angle of flare for the 

extended zone is determined by using a straight line that starts at the estimated location of the ILS 

antenna, 1,000 feet from the opposite runway threshold, intercepts the defined zone perimeter distance at 

the runway threshold, and terminates at the end of the extended zone. The example RI zone in Figure 7 

uses a one-dot ILS deviation, and the zone ends at 14,265 feet past the threshold, as determined by the 3-

degree ILS slope shown in Figure 6. 

All values for RI zone placement can be modified in configuration files to be optimal for any airport. 

Site-specific adaptation of some values may be necessary due to conditions at individual airports. For 

example, if parallel runways are closely spaced, runway zones may need to be narrower. Airports in 

mountainous regions may require steeper glide slopes. Construction at airports may cause runway 

dimensions to change or may lead to creation of new runways or removal of existing runways. 

. . .

Runway

Touchdown

Point

Runway Incursion Zone

800 ft

Zone

Altitude

Approx. 15, 265 ft

Runway

Threshold

3°

Approx. 14,265 ft

16
Figure 7. Example Extended Runway Zone with 1 Dot ILS Deviation 

5.4.3 Incursion Scenarios and Alert Criteria

RSM is designed to detect all possible runway incursion scenarios including conflicts on single 

runways, intersecting runways and intersecting flight paths. This capability is accomplished using a 

generic approach that is based on the concept of ownship and traffic operational states as defined in 

Appendix A. Conflict scenarios are defined by the combination of operational states that determine 

whether or not alert criteria should be tested for conflicts. There are separate criteria for single runway 

and intersecting runway/flight path conflicts. Appendix B describes the alert criteria and default 

thresholds and provides a set of tables that define the scenario conditions for all possible combinations of 

ownship and traffic states. Appendix C provides a mapping between RSM operational states and SURF 

IA operational states, and RTCA 2010b describes the criteria, thresholds, and state combination tables for 

SURF IA indications. 

5.4.4 Determining Operational States

Since incursion scenarios and indication and alert criteria are based on the operational states of 

ownship and traffic (Section 5.4.3 above), the correct performance of RSM depends on, among other 

things, how accurately these states are determined. The criteria and data for determining states include on 

or off the runway, heading/track in direction of runway, ground speed, acceleration, altitude and vertical 

speed. 

Additional data may also be available for determining ownship states such as auto throttle, engine 

pressure ratio (EPR) mode, throttle position, thrust reversers, air-ground, nose wheel squat, etc. (see 

Appendix D and Table D1). Ownship states can be computed accurately because the additional data help 

to indicate “intent” to takeoff, “intent” to land, etc. However, these intent data are not available for 

traffic. Although RSM has good results in computing traffic states without the intent data, accuracy could 

potentially be improved if this data becomes available. See discussion on intent data in Appendix E. 

5.4.5 Alert Output Data

The current alert output parameters for the RSM caution and warning, that provide the flight crew 

with optimal alert awareness, are based on the aural and graphical display requirements developed 

Runway

Thresholds

Approx. 14,265 ft. 175 ft.

175 ft. 1,000 ft.

Zone

End

1 Dot

1 Dot

Extended Runway 

Incursion Zone

ILS

Localizer

17
through simulation and flight testing. The current parameters are listed in Section 4.3. Additional 

parameters are available in RSM and can be provided in future upgrades as required. 

5.5 LACM 

5.5.1 Integration with TCAS

LACM is designed to detect and alert for air-to-air conflicts at low altitudes near the airport without 

conflicting with TCAS operation. As mentioned in Section 2.2, TCAS resolution advisories are inhibited 

below 1000 feet AGL ±100 feet and aural traffic advisories are inhibited below 500 feet AGL. LACM 

monitors for conflicts below 1000 feet AGL. Any overlap in coverage with TCAS will require 

integration and coordination so LACM does not interfere with existing TCAS operations. For example, 

LACM will not alert if TCAS is already alerting for the same traffic. Research regarding LACM and 

TCAS integration is necessary. The results of this research could possibly support RTCA SC-147 

objectives (see Section 2.2). 

5.5.2 Traffic Data and Computations

A major difference between LACM and TCAS design is the way traffic data is acquired and the 

resulting methods of computing distance to aircraft, bearing, and closing speed. TCAS uses Mode S and 

Mode C surveillance of nearby airborne traffic at exact time intervals to continually measure the distance 

(range), direction (bearing), and altitude (if available). This system provides accurate, timely, and 

consistent data to compute parameters. TCAS determines closing speed between ownship and traffic by 

interrogating nearby Mode C or Mode S transponder-equipped traffic and using the position data to 

compute changes in distance over time. 

Currently, LACM does not use TCAS Mode-S/Mode-C data directly but primarily depends on data 

available from ADS-B. (See Section 4) Closing speed is critical in determining the timing of a potential 

conflict. During previous RSM research, closing speed had been calculated using ADS-B aircraft 

position data, and the timestamps associated with that data. However, flight testing found that using 

ADS-B position reports and associated timestamps to calculate closing speeds produced erratic results 

since neither of these data items were reported with sufficient accuracy. Future upgrades to ADS-B may 

improve accuracy and timeliness; however, an immediate solution is needed. 

Another method of computing closing speed is to use ADS-B ground speeds that are consistent and 

not as dependent on time stamps as position data. By computing the components of ground speed in the 

direction of closure for both ownship and traffic, and comparing these components, the closing speeds 

and times to CPA are highly accurate and smooth (not erratic). This method of computation is currently 

used by LACM when ADS-B is the data source. Further testing is needed to determine how sensitive this 

method is to variations in flight data accuracy. 

5.5.3 Monitoring and Alert Criteria

Since LACM is designed to operate at low altitudes, the monitoring and alert criteria and thresholds 

must be optimized to prevent nuisance alerts and allow sufficient lead time for avoidance action to 

prevent collisions. The current alert criteria are based on those used by TCAS but thresholds may differ 

based on testing and operational requirements (e.g., approach spacing, etc.). For example, criteria for 

time to CPA (range tau) and time to co-altitude (vertical tau), may have different thresholds for LACM, to 

customize the lead time for pilot response to alerts. Also, to prevent nuisance alerts, some additional 

LACM criteria are required such as projected separation at CPA, relative altitude at CPA, and position of 

CPA on the ground or airborne. Table 1 lists the initial traffic monitoring and alert criteria, and 

thresholds that have been determined based on developmental testing and evaluation. The threshold 

values for monitoring and alerts are contained in software configuration files and can be modified as 

18
required based on future testing. For a caution or warning to be issued, all criteria listed in the table must 

be satisfied. 

For LACM criteria which specify a distance threshold, the distance is measured from the aircraft 

center of gravity (CG). Distance between ownship and traffic is measured from the ownship CG to the 

traffic CG. 

Table 1. Initial LACM Alert Criteria and Thresholds 

Monitoring Criteria

Target proximity < 18000 ft from ownship position.

Ownship and target altitudes 50 – 1000 ft AGL ±100 ft.

Alert Criteria Caution Warning

Range tau (sec) <35 <20

OR current distance to target (range) (ft) <2000 <1200

Vertical tau (sec) <35 <20

OR current relative altitude (ft) <1000 <400

OR projected relative altitude at CPA (ft) <1000 <400

Projected horizontal separation at CPA (ft) <2000 <1200

Projected ownship and/or target altitudes at CPA (ft) 

(Own/target not near the ground at CPA)

>50 >50

5.5.4 Alert Data Output

The parameters that are output for the LACM caution and warning depend on the cockpit alerting 

display (aural and graphical) requirements for NextGen. The future alert display requirements are 

unknown at this time, but a list of parameters can be constructed based on previous RIPS alert output as 

well as display data currently utilized by TCAS. The following list of alert output parameters is based on 

developmental testing and evaluation but is subject to change based on future testing and requirements. 

Alert parameters previously used for RIPS are identified with asterisks. 

 Traffic ID (e.g., ICAO aircraft address)* 

 Alert code (includes type of alert caution/warning, traffic runway, traffic arrival/departure state)* 

 Distance to traffic (range)* 

 Time (sec) to collision or closest point of approach (range tau)* 

 Bearing 

 Traffic air or ground 

 Relative altitude (if airborne) 

 Traffic climb/descend (if airborne) 

 Time (sec) to co-altitude (vertical tau) (if airborne) 

5.6 TCM 

In taxi scenarios, the traffic may be an aircraft or a surface vehicle. In this discussion, the term 

"vehicle" refers to both aircraft and surface vehicles. 

5.6.1 Data Accuracy

A high degree of data accuracy is necessary because of the very close distance and time tolerances 

involved in surface conflict situations and the greater likelihood of nuisance alerting. The criteria and 

threshold tables in the next section indicate the accommodations TCM makes for variations in data 

accuracy. 

19
Ground speed accuracy can be problematic since reported ground speed can be incorrect by more than 

one knot, and a stationary vehicle may report a non-zero ground speed. Therefore, TCM allows for a 

discrepancy of up to two knots for reported ground speed. 

Specific data accuracy requirements are yet to be determined. 

5.6.2 Monitoring and Alert Criteria

Since TCM is designed to operate only when the ownship is on the ground, the monitoring and alert 

criteria and associated thresholds must be optimized for much closer tolerances than for airborne 

operations. The thresholds must be set to allow sufficient lead times to prevent collisions but minimize or 

eliminate over-alerting. 

For TCM criteria which specify a distance threshold, the distance is measured differently from RSM 

and LACM, due to the closer proximity between vehicles and the need for greater precision. Distance for 

TCM is measured from the vehicle exterior instead of from the aircraft CG. For example, if ownship is 

following traffic, the distance between vehicles is measured from the ownship nose to the traffic tail. 

Table 2 lists the monitoring criteria, alert criteria and thresholds that have been determined based on 

developmental and simulation testing [Jones et al., 2009 and Jones et al., 2010]. These criteria are applied 

in a three-step process. 

5.6.2.1 Step 1 – General Criteria

In Step 1, monitoring criteria determine what traffic is monitored for conflicts, and alert criteria 

determine if and which alerts to issue. The threshold values for monitoring and alerts are contained in 

software configuration files and can be modified as required based on future testing. For a caution or 

warning to be issued, all criteria for Step 1 (see Table 2) must be satisfied. The threshold modification 

factors listed in Table 3 are secondary criteria that modify the standard thresholds to prevent nuisance 

alerting and alert toggling (alerts on and off or switching between caution and warning). 

In Table 2, special treatment is given to the minimum separation threshold for cautions. The standard 

value for this threshold is 50 feet, but a larger value may be used, depending on vehicle size. If either the 

ownship radius or the traffic radius is greater than 50 feet, the radius of the larger vehicle is used for 

minimum separation. For example, if ownship is a B757 with a body radius of 77.4 feet, and the target is 

a DC3 with a body radius of 32.5 feet, then 77.4 feet would be the threshold value. Vehicle size is not 

used to determine the minimum separation threshold for warnings, which has a standard value of 30 feet. 

5.6.2.2 Step 2 – Following Criteria

If Step 1 does not issue an alert, then Step 2 is applied. Step 2 has a single criterion, which is only 

applied if one vehicle is following the other. 

The goal of this step is to calculate a safe separation distance for the following vehicle, so that an alert 

may be issued if separation is not adequate. This distance threshold is calculated using the following 

vehicle's ground speed and body length. 

The criterion in Table 2, “Ground speed per body length of separation”, specifies the ground speed at 

which the distance threshold is equal to one body length of separation. This criterion is abbreviated 

bodyLengthKnots . The default values are 8 knots for a caution, and 11 knots for a warning. 

If ground speed is greater than bodyLengthKnots, then the required separation is proportionally 

larger than one body length. If ground speed is less than bodyLengthKnots, then the required 

separation is proportionally less than one body length. The formula is below: 

(groundSpeed / bodyLengthKnots) * bodyLength = separationThreshold

20
Table 2. Initial TCM Alert Criteria and Thresholds 

Monitoring Criteria

Target proximity < 1500 ft from ownship position.

Either ownship or target speed must be > 5 kts. (No alert if both stopped or both < 5 kts)

Alert Criteria – Step 1

Standard Thresholds*

Threshold 

Modification Factors

Modified 

Thresholds

Caution

WA

+ CA+

WA

+

Range tau (sec) 18 10 one stopped 12 7

slower taxi 16 7

same Direction 12 7

Turning 12 7

Following 10 7

head-on 18 10

turning head-on no

limit

10

Current distance to target 

(range)

< min alert distance (ft)

700 400 one stopped AND

slower taxi

150 150

turning AND

in path

150 150

head-on 900 600

Projected separation at CPA 

< min separation (ft)

 OR

Current distance to target 

(range) 

< min separation (ft)

Maximum:

50, or

ownship radius, or

target radius

30 one stopped

AND slower taxi

15 15

not one stopped

AND slower taxi

AND same Direction

AND in path

10 10

slower taxi

AND range tau = 0

20 20

one stopped

OR slower taxi

40 30

WA in progress 60 45

CA in progress 60 30

Alert Criteria – Step 2

Threshold 

Modification Factors CA WA

Ground speed per body length of separation (kts)

(use body length of vehicle that is following)

Following 8 11

Alert Criteria – Step 3 CA WA

Current distance to target (range) = very close (ft) <10 0

* Standard thresholds are used when no threshold modification factors apply. 

+ CA = caution WA = warning 

21
Table 3. Initial TCM Threshold Modification Factors 

Threshold Modification 

Factors

Description

One stopped At least one vehicle is stopped or moving < 2 kts.

Slower taxi Both vehicles are taxiing < 15.5 kts. (One can be stopped.)

Same direction Both vehicles are moving in the same direction within ±50° of 

heading.

Turning One or both vehicles is/are turning with turn rate > 4°/sec.

Following One vehicle is following the other and neither is stopped.

In path One of the vehicles is in the path of the other, and neither is stopped

Head-on Both vehicles are in each other’s paths within ±15°.

Turning head-on Ownship is turning with turn rate > 4°/sec, and turn is projected to 

cause head-on conflict, with paths within ±15°. Condition has lasted 

for at least 5 seconds. Traffic may be stopped or moving.

For example, if ownship is a B757, body length 154.8 feet, taxiing behind a DC3 at 15 knots, then the 

separation threshold to trigger a caution is: 

(15 / 8) * 154.8 = 290.25 feet

The separation threshold to trigger a warning is: 

(15 / 11) * 154.8 = 211.09 feet

So a caution is triggered if ownship follows within 290.25 feet of the traffic, and a warning is triggered if 

ownship follows within 211.09 feet. 

If ownship was in front and the traffic was following, the DC3 body length of 65.0 feet would be 

used, instead of 154.8 feet, and traffic ground speed would be used instead of 15 knots. 

5.6.2.3 Step 3 – Close Traffic Criteria

If neither Step 1 nor Step 2 issues an alert, then Step 3 is applied. If the two vehicles are within 10 

feet of each other, but do not otherwise prompt alerts, a caution is issued. 

5.6.3 Alert Data Output

The parameters that are output for the TCM caution and warning depend on the cockpit alerting 

display (aural and graphical) requirements for NextGen. The future alert display requirements are 

unknown at this time, but a list of parameters can be constructed based on previous RIPS alert output. 

The following is a list of initial parameters that is subject to change based on future testing and 

requirements. Alert parameters previously used for RIPS are identified with asterisks. 

 Traffic ID (e.g., ICAO aircraft address)* 

 Alert code (type alert caution/warning, traffic runway and traffic arrival/departure state if 

applicable)* 

 Distance to traffic (range)* 

 Time (sec) to collision or closest point of approach (range tau)* 

 Bearing 

22
6 Initial Description of ATCAM Resolution Advisories 

The need or efficacy of Resolution Advisories (RA) for an aircraft-based CD&R system for ATMA 

operations has not been firmly established by research. To conduct this research, RA implementations 

have been created as outlined in this section. Various means are being used to validate this concept, such 

as qualitative pilot evaluation, automated simulation, and piloted simulation. Limited testing of the 

efficacy of recommending avoidance maneuvers has been performed but conclusive results have not been 

achieved. 

6.1 Resolution Advisories 

When ATCAM determines that a conflict has occurred, either a warning, indicating that ownship 

must take avoidance action, or a less severe caution, or both, are issued. When ATCAM issues a 

warning, an RA may also be issued, indicating the maneuver that should be performed by ownship to 

deconflict a possible collision or incursion. Currently, ATCAM determines the resolution maneuver 

based on the conflict scenario. Navigational data, such as turning angle or climb rate, may accompany the 

RA, depending on the scenario. 

If ATCAM issues multiple warnings, an RA is only issued based on the first alert. ATCAM currently 

does not consider the second conflict when determining the RA. Similarly, ATCAM currently does not 

perform any coordinated resolutions with the traffic like TCAS (i.e., it does not project whether the 

resolution maneuver will create a new conflict with other traffic or if the resolution maneuvers being 

performed by each vehicle might in fact conflict). 

6.2 RSM RAs 

This section outlines the approach taken for runway conflict RAs, in RSM. 

6.2.1 RSM Avoidance Maneuvers

Table 4 lists the avoidance maneuvers that ATCAM currently defines for runway conflicts. RSM 

RAs only indicate a recommended maneuver, and do not provide navigational guidance. 

Table 4. RSM Avoidance Maneuvers 

Avoidance Maneuver Description

No Resolution Available No viable resolution found, leave 

resolution to pilot discretion

Go Around Terminate approach and climb away

Touchdown Emergency 

Stop

Expedite landing, decelerate quickly

Reject Takeoff Abort takeoff, stop 

Emergency Stop Stop immediately (severe slowdown 

may suffice)

Exit/Clear Runway Proceed immediately to nearest 

runway exit

6.2.2 RSM Maneuver Selection

When RSM issues a warning, avoidance maneuvers are considered as shown in Table 5, for each 

ownship/traffic combination. These maneuvers are usually considered in the order shown. 

RSM considers a maneuver by projecting whether or not it will prevent the possible collision. If so, 

that maneuver is used for the RA, and no other maneuvers will be considered. If not, other maneuvers in 

the list will be considered. If none of the candidate maneuvers is projected to prevent the collision, RSM 

issues a ‘No Resolution Available’ maneuver. 

23
Table 5. RSM Scenario Resolutions 

Ownship

State

Traffic

State *

Single Runway

Avoidance Maneuvers

Intersecting Runway

Avoidance Maneuvers

taxi taxi NA NA

takeoff roll Emergency Stop 

Exit/Clear Runway

NA

climb-out Emergency Stop 

Exit/Clear Runway

NA

approach Emergency Stop 

Exit/Clear Runway

NA

rollout Emergency Stop 

Exit/Clear Runway

NA

fly-thru NA NA

pre-takeoff taxi Reject Takeoff 

Exit/Clear Runway

NA

takeoff roll Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

climb-out Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

approach Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

rollout Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

fly-thru Reject Takeoff NA

takeoff roll taxi Reject Takeoff 

Exit/Clear Runway

NA

takeoff roll Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

climb-out Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

approach Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

rollout Reject Takeoff 

Exit/Clear Runway

Reject Takeoff

fly-thru Reject Takeoff NA

approach taxi Go Around

Touchdown Emergency Stop

NA

takeoff roll Go Around

Touchdown Emergency Stop

Touchdown Emergency Stop

climb-out Go Around

Touchdown Emergency Stop

Touchdown Emergency Stop

approach Go Around Go Around

Touchdown Emergency Stop

rollout Go Around

Touchdown Emergency Stop

Go Around

Touchdown Emergency Stop

fly-thru Touchdown Emergency Stop 

Go Around

NA

rollout taxi Emergency Stop 

Exit/Clear Runway

NA

takeoff roll Emergency Stop 

Exit/Clear Runway

Emergency Stop 

climb-out Emergency Stop 

Exit/Clear Runway

Emergency Stop 

approach Emergency Stop 

Exit/Clear Runway

Emergency Stop 

rollout Emergency Stop 

Exit/Clear Runway

Emergency Stop 

fly-thru Emergency Stop NA

* Pre-takeoff state is not currently defined for traffic. ‘NA’ indicates no alert will be issued, so no resolution is necessary.

24
Different methods are used to forecast the results of the various maneuvers. ‘Go Around’ is forecast 

by simulating a climb at 480 ft per minute by ownship, and projecting ownship and traffic positions into 

the future, one second at a time, until time to conflict is 0 seconds. At any one-second interval projection, 

if the conflict is found to no longer exist, then ‘Go Around’ is considered to be a successful maneuver. 

On the other hand, if the conflict exists until ownship passes the projected point of conflict, then the ‘Go 

Around’ maneuver is considered to fail. 

The maneuvers ‘Emergency Stop’, ‘Touchdown Emergency Stop’, and ‘Reject Takeoff’ are forecast 

by first calculating whether ownship can stop in time to prevent a collision, and then calculating whether 

a conflict will exist once ownship has stopped. If ownship can stop in time and no conflict will exist 

afterward, the maneuver is considered to be successful; otherwise, it is considered to fail. Stopping 

distance for ‘Touchdown Emergency Stop’ and ‘Reject Takeoff’ is calculated using a deceleration rate of 

-8 kts per second per second. For ‘Emergency Stop’, a deceleration rate of -5 kts per second per second is 

used. 

The maneuver ‘Exit/Clear Runway’ is actually not forecast at all, but is issued as a default second 

choice in some scenarios. If the maneuver of first choice fails, then ‘Exit/Clear Runway’ will be used. 

This maneuver is discussed more below, under “Runway Exits”.

6.2.3 RSM Unresolved Scenarios

As shown in Table 6, all scenarios in which ownship is in climb out or fly through states are assigned 

‘No Resolution Available’.

Table 6. RSM Unresolved Scenarios 

Ownship

State

Traffic

State

Single Runway

Avoidance Maneuvers

Intersecting Runway

Avoidance Maneuvers

climb-out taxi No Resolution Available NA

takeoff roll No Resolution Available No Resolution Available

climb-out No Resolution Available No Resolution Available

approach No Resolution Available No Resolution Available

rollout No Resolution Available No Resolution Available

fly-thru No Resolution Available NA

fly-thru taxi NA NA

takeoff roll No Resolution Available NA

climb-out No Resolution Available NA

approach No Resolution Available NA

rollout No Resolution Available NA

fly-thru NA NA

6.2.4 Runway Exits 

RSM currently does not maintain data on runway exit locations, so the ‘Exit/Clear Runway’ 

maneuver requires clarification. There is no way of discerning whether ownship can reach the nearest 

exit in time to escape a conflict situation. However, if ownship is on the runway and the other viable 

maneuvers, such as ‘Emergency Stop’ or ‘Reject Takeoff’ do not avoid the conflict, ownship must get out 

of the way somehow, if a true conflict (i.e., not a false alarm or nuisance alert) is confirmed. 

The current interpretation of ‘Exit/Clear Runway’, then, is that the pilot must determine the most 

appropriate location to exit or clear the runway. If reaching a runway exit is not feasible, then the pilot 

should look for another way to get off of the runway, or to move to the side of the runway as far as 

practical. RSM performs no calculation to predict the success of ‘Exit/Clear Runway’.

A similar issue exists for TCM, when exiting seems a viable maneuver for a taxiing ownship. TCM’s 

approach to this issue is described later, in Section 6.4.4, Taxiway Exits. 

25
6.3 LACM RAs

This section outlines the approach taken for low altitude conflict RAs, in LACM. 

6.3.1 LACM Avoidance Maneuvers 

As shown in Table 7, LACM avoidance maneuvers are composed of three separate dimensions: 

vertical, horizontal, and acceleration maneuvers. Navigational guidance can be provided for each 

dimension. 

In theory, it is possible for an LACM RA to combine maneuvers from multiple dimensions. For 

example, a single maneuver may involve a vertical climb and a right turn, while accelerating. In practice, 

though, all of the currently-supported maneuvers only involve a single dimension. 

Table 7. LACM Avoidance Maneuver Combinations 

Avoidance

Maneuver

Navigational

Data

Description

V:H:A v:h:a Perform a combination of:

 Vertical maneuver V, with navigational data v,

 Horizontal maneuver H, with navigational data h, and

 Acceleration maneuver A, with navigational data a.

No Resolution

Available

No viable resolution found, leave resolution to pilot 

discretion

6.3.1.1 LACM Vertical Maneuvers 

Table 8 lists the vertical avoidance maneuvers that ATCAM defines for low altitude conflicts. 

LACM RAs indicate a recommended vertical maneuver, coupled with navigational guidance which is the 

required vertical rate in feet per minute. 

Table 8. LACM Vertical Avoidance Maneuvers 

Avoidance

Maneuver (V)

Navigational

Data (v fpm)

Description

Min Max Step

No Change Maintain current vertical 

trajectory

Climb 500 4400 100 Climb at a rate of v feet per 

minute.

Reduce Climb 1 1 0 Reduce rate of climb to v feet 

per minute. (Currently used 

only to implement ‘Level Off’.)

If the vertical maneuver is ‘No Change’, the avoidance maneuver does not have a vertical dimension. 

Navigational Data is listed as a range, because LACM attempts to find the least disruptive maneuver 

which will avert the conflict. LACM first attempts a maneuver using the minimum navigational value 

listed under ‘Min’. If that maneuver does not avert the conflict, LACM adds the value under ‘Step’ to the 

navigational value, and tries again, and keeps incrementing the navigational value by ‘Step’ until it is 

determined that the conflict is averted. The successful value is then included in the RA. If the 

navigational value reaches the maximum value ‘Max’ without averting the conflict, then the maneuver 

fails. 

26
The ‘Climb’ maneuver is implemented by first trying a climb at 500 feet per minute. If this climb 

does not avert the conflict, then LACM tries a climb at 600 feet per minute, then 700 feet per minute, and 

so on, until a navigational value is found, or until 4,400 feet per minute is tried. LACM chooses this 

maximum climb rate of 4,400 feet per minute because TCAS also uses that maximum value. However, 

smaller aircraft are not able to climb at such a high rate. ATCAM may be adapted in future version to 

make such navigational data configurable, according to aircraft type. 

‘Reduce Climb’ is currently used only to implement a maneuver identical to ‘Level Off’. It was 

meant specifically to address a takeoff scenario in which traffic was too high to climb over, and turning 

was not effective. The maneuver directs the pilot to fly under the traffic. Further testing is needed to 

determine the viability of this maneuver. 

A climb rate of 1 foot per minute is used for ‘Reduce Climb’, instead of 0 feet per minute. This value 

is used because the LACM code internally assumes that a climb rate of 0 indicates that no vertical 

maneuver is intended, and 1 foot per minute is nearly level. 

6.3.1.2 LACM Horizontal Maneuvers 

Table 9 lists the horizontal avoidance maneuvers that ATCAM defines for low altitude conflicts. 

LACM RAs indicate a recommended horizontal maneuver, coupled with navigational guidance which is 

the angle in degrees by which to turn. 

Table 9. LACM Horizontal Avoidance Maneuvers

Avoidance

Maneuver

(H)

Navigational Data

(h degrees)

Description

Min Max Step

No Change Maintain current horizontal trajectory.

Bear Right 10 60 10 Bear to the right by h degrees. 

Bear Left -10 60 -10 Bear to the left by h degrees. 

If the horizontal maneuver is ‘No Change’, the avoidance maneuver does not have a horizontal 

dimension. 

Navigational Data is listed as a range, and LACM steps through horizontal navigational values in the 

same way it steps through vertical navigational values. 

For example, the ‘Bear Right’ maneuver is implemented by first trying a right turn of 10 degrees. If 

this turn does not avert the conflict, then LACM tries a right turn of 20 degrees, then 30 degrees, and so 

on, until a navigational value is found, or until 60 degrees is tried. ‘Bear Left’ is implemented in the same 

fashion. 

6.3.1.3 LACM Acceleration Maneuvers 

Acceleration avoidance maneuvers are currently not implemented (Table 10). More analysis is 

needed to determine how maneuvers such as reduce and increase speed can realistically be recommended. 

Acceleration maneuvers would seem to be more dependent on the capabilities of the individual aircraft 

than vertical or horizontal maneuvers. 

Table 10. LACM Acceleration Avoidance Maneuvers 

Avoidance

Maneuver (A)

Navigational

Data (a)

Description

No Acceleration 

Maneuver

Maintain current velocity.

27
6.3.2 LACM Maneuver Selection 

When LACM issues a warning, avoidance maneuvers are considered in the order below. If the first 

maneuver fails, the second is tried, and so on, until the end of the list. 

 ‘Vertical Climb’, determining the climb rate as described above. 

 ‘Level Off’/‘Reduce Climb’ maneuver.*

 ‘Bear Right’, determining the turn angle as described above. 

 ‘Bear Left’, determining the turn angle as described above. 

 ‘No Resolution Available’.

* If ‘Level Off’ is successful, LACM actually issues a ‘Reduce Climb’ RA, with a climb rate of 1 fpm.

LACM considers a maneuver by forecasting whether or not it will prevent the possible collision. 

Each maneuver is forecast by simulating vertical or horizontal movement by ownship, and projecting 

ownship and traffic positions into the future, one second at a time. If, at any one-second interval, the 

conflict is found to no longer exist, then the maneuver is considered to be successful. On the other hand, 

if the conflict exists until ownship passes the point of conflict, then the maneuver is considered to fail. 

6.4 TCM RAs

This section outlines the approach taken for taxi conflict RAs, in TCM. 

6.4.1 TCM Avoidance Maneuvers

Table 11 lists the avoidance maneuvers that ATCAM defines for taxi conflicts. TCM RAs only 

indicate a recommended maneuver, and do not provide navigational guidance. 

Table 11. TCM Avoidance Maneuvers 

Avoidance

Maneuver

Description

No Resolution

Available

No viable resolution found, leave resolution to pilot 

discretion

Emergency Stop Stop immediately (severe slowdown may suffice)

Slow Down Reduce taxi speed

Speed Up Increase taxi speed 

6.4.2 TCM Maneuver Selection

When TCM issues a warning, avoidance maneuvers are considered in the order below. If the first 

maneuver fails, the second is tried, and so on, until the end of the list. 

 ‘Slow Down’

 ‘Emergency Stop’

 ‘Speed Up’

 ‘No Resolution Available’.

TCM considers a maneuver by forecasting whether or not it will prevent the possible collision. Each 

maneuver is forecast by simulating acceleration or deceleration by ownship, and projecting ownship and 

traffic positions into the future, one second at a time. If, at any one-second interval, the conflict is found 

28
to no longer exist, then the maneuver is considered to be successful. On the other hand, if the conflict 

exists until ownship passes the point of conflict, then the maneuver is considered to fail. 

6.4.3 TCM Unresolved Scenarios 

TCM currently assigns ‘No Resolution Available’ for head-on conflicts, in which ownship and traffic 

are moving in opposite directions toward each other. None of the currently-supported maneuvers allow 

ownship to move out of the way of traffic in this scenario. 

6.4.4 Taxiway Exits 

TCM currently does not maintain data on taxiway locations. If ownship is on a taxiway, TCM has 

no way of discerning whether ownship can reach the nearest taxiway intersection in time to escape a 

conflict situation. In a large gate area or a wide taxiway intersection, ownship has more flexibility, but 

TCM cannot exploit this flexibility without taxiway or gate knowledge. 

A similar issue exists for RSM, when exiting the runway is the only viable maneuver. RSM does not 

maintain runway exit data, but still uses the ‘Exit/Clear Runway’. An ‘Exit Taxiway’ maneuver could be 

considered for TCM. Currently, though, ‘No Resolution Available’ is used in such scenarios. Taxi 

speeds are slower, so split-second reaction is less critical, and 'Exit' sometimes makes less sense while 

taxiing, for example in gate areas. 

If, in the future, taxiway data and taxi routing information are added to ATCAM, then a 'Turn Right' 

and 'Turn Left' maneuver could be added which specifies which taxiway to turn onto. With such 

additional data, ATCAM would be able to confidently project whether ownship can reach the next 

intersection in time, whether the intersecting taxiway is already occupied by other traffic, or whether any 

traffic is approaching that taxiway. 

6.5 Pilot Reaction Delays 

To realistically forecast the potential success of a candidate avoidance maneuver, ATCAM includes 

an estimated pilot reaction delay. A pilot does not respond to an alert instantaneously. Some time is 

taken to notice and understand the alert and decide on a response, before undertaking avoidance action. If 

ATCAM were to assume immediate action, the pilot may not be able to perform the recommended 

maneuver in time to avoid the conflict as predicted. 

ATCAM estimates pilot delay periods as listed in Table 12. The values were obtained from 

averaging pilot reaction data from previous flight and simulation studies. Pilot delays are not listed for 

RSM operational states climb-out and fly-thru, since RAs are currently not issued when ownship is in 

those states. 

Table 12. Estimated Pilot Delays 

Algorithm Operational

State

Pilot Delay

(seconds)

RSM approach 5

RSM rollout 3

RSM taxi 2

RSM pre-takeoff 2

RSM takeoff roll 2

LACM 3

TCM 2

If an alert is not already in progress when a warning alert is issued, ATCAM calculates that ownship 

will continue on its current trajectory during the pilot delay period, before ownship performs the 

maneuver. For example, if ownship is on approach, ATCAM calculates whether a Go Around will work 

29
by projecting that ownship will continue its approach for five seconds, and will then begin the Go Around 

climb. 

If an RA is already in progress from a previous warning alert and a new warning alert is issued, 

ATCAM attempts to use the avoidance maneuver from the alert already in progress to resolve the latest 

conflict. In this case, ATCAM does not consider the pilot delay to decide whether the maneuver can still 

avoid the conflict, since the pilot delay has already been accounted for in the initial calculation. 

7 Summary 

NASA is conducting research to enable safe airport operations for both current and future NextGen 

operations. Aircraft-based conflict detection and alerting algorithms (known as the Airport Traffic 

Collision Avoidance Monitor (ATCAM)) are being developed to detect potential traffic conflicts in the 

terminal area and generate indications and alerts that can be displayed to the pilot. 

ATCAM is comprised of three separate but integrated algorithms that operate at low altitudes near the 

airport, on the runway, and during taxi and ramp operations for multiple classes of aircraft as well as 

surface vehicles. The Runway Safety Monitor (RSM) detects runway incursion conflicts and generates 

indications and alerts that provide the flight crew with sufficient awareness to take action to avoid a 

collision. RSM has been under development and testing for many years and has proven to be effective in 

reducing all types of runway incursions and eliminating the most severe incursions. The Low Altitude 

Conflict Monitor (LACM) detects and alerts for air-to-air conflicts at low altitudes near the airport 

without conflicting with TCAS. The Taxi Conflict Monitor (TCM) detects and alerts for ground taxi 

conflicts anywhere in the airport movement and ramp areas. LACM and TCM are in development; 

however, initial testing has proved to be very promising for elimination of collisions in these operating 

areas. The technical approaches for each of these algorithms are presented in this report along with the 

data communications that are necessary for successful implementation and integration. 

Work is currently in progress to test and refine the algorithms as part of NextGen research. This work 

is also being closely coordinated with other NASA research in emerging NextGen technologies including 

synthetic and enhanced vision systems and 4D surface operations. On-going surface safety research also 

includes determination of the feasibility and development of requirements for conflict resolution 

advisories. 

30
References 

[Ballin et al., 2002] Ballin, M. G., Hoekstra, J. M., Wing, D. J., and Lohr, G. W., 2002, NASA Langley 

and NLR Research of Distributed Air/Ground Traffic Management. Proceedings of the AIAA 

Aircraft Technology, Integration, and Operations (ATIO) Technical Conference. 

[Cassell et al., 2003] Cassell, R., Ever, C., and Esche, J., 2003, Safety Benefits of PathProxTM - A Runway 

Incursion Alerting System. Proceedings of the 22nd Digital Avionics Systems Conference. 

[Cheng et al., 2003] Cheng, V. L., Yeh, A., and Foyle, D. C., 2003, Evaluation Plan for an Airport 

Surface-Operation Automation Concept. Proceedings of the AIAA 3rd Aviation Technology, 

Integration, and Operations (ATIO) Technical Forum, Paper AIAA 2003-6796. 

[Cheng et al., 2009] Cheng, V. H. L., Andre, A. D., and Foyle, D. C., 2009, Information Requirements 

for Pilots to Execute 4D Trajectories on the Airport Surface. 2009 AIAA Aviation Technology, 

Integration, and Operations Conference. 

[Era, 2008] Era Corporation, 2008, Squid by Era, <www.erabeyondradar.com/squid-by-era>.

[EUROCAE, 2007] European Organization for Civil Aviation Equipment (EUROCAE), 2007, Minimum 

Aviation System Performance Specification for Advanced Surface Movement Guidance and 

Control System (A-SMGCS), Draft version 0.06 ED-87B.

[Evans, 2007] Evans, Brian, June 2007, In-Trail, On-Time, Avionics Magazine. 

[FAA, 2000] Federal Aviation Administration, November 2000, Introduction to TCAS II, Version 7. 

[FAA, 2007] Federal Aviation Administration, October 2007, Notice of Proposed Rulemaking –

Automatic Dependent Surveillance – Broadcast (ADS-B) Out Performance Requirements to 

Support Air Traffic Control (ATC) Service, Docket No. FAA-2007-29305, Notice No. 07-15. 

[FAA, 2009] Federal Aviation Administration, 2009, Flight Crew Alerting, Advisory Circular 25.1322-

1X (draft). 

[FAA, 2009a] Federal Aviation Administration, 2009, Annual Runway Safety Report 2009, Air Traffic 

Organization. 

[FAA, 2010] Federal Aviation Administration, 2010, Final rule – Automatic Dependent Surveillance –

Broadcast (ADS-B) Out Performance Requirements to Support Air Traffic Control (ATC) Service, 

Docket No. FAA-2007-29305, Amdt. No. 91-314. 

[FAA, 2011] Federal Aviation Administration, 2011, ATO Safety, National Runway Safety Plan, V 1.0. 

[Foyle et al., 2011] Foyle, D. C., Hooey, B. L., Bakowski, D. L., Williams, J. L., and Kunkle, C. L., 

2011, Flight Deck Surface Trajectory-based Operations (STBO) Simulation Results and ConOps 

Implications. Ninth USA/Europe Air Traffic Management Research and Development Seminar, 

ATM2011. 

[Foyle et al., 2009] Foyle, D. C., Hooey, B. L., Kunkle, C. L., Schwirzke, F. J., and Bakowski, D. L., 

2009, Piloted Simulation Of NextGen Time-based Taxi Clearances and Tailored Departures. 

31
Proceedings of the 2009 IEEE/AIAA Integrated Communications, Navigation and Surveillance 

Conference. 

[Green, 2006] Green, David F., 2006, Runway Safety Monitor Algorithm for Single and Crossing 

Runway Incursion Detection and Alerting, NASA/CR-2006-214275. 

[Green et al., 2009] Green, D. F., Otero, S. D., Barker, G. D., and Jones, D. R., 2009, Initial Concept for 

Terminal Area Conflict Detection, Alerting, and Resolution Capability On or Near the Airport 

Surface, NASA/CR-2009-215696. 

[Hoekstra et al., 2002] Hoekstra, J. M., van Gent, R. N. H. W., and Ruigrok, R. C. J., 2002, Designing for 

Safety: The ’Free Flight’ Air Traffic Management Concept. Reliability Engineering and System 

Safety 75, pp. 215-232. 

[Honeywell, 2006] Honeywell International Inc., 2006, Runway Awareness and Advisory System (RAAS) 

Product Description. 

[Hughes, 2007] Hughes, David, 2007, Honeywell, Sensis Demonstrate Runway Incursion Warnings In 

the Cockpit, Aviation Week, September 3, 2007, p. 67. 

[ICAO, 1997] International Civil Aviation Organization, 1997, Draft Manual of Advanced Surface 

Movement Guidance and Control Systems (A-SMGCS), 16th Meeting of the International Civil 

Aviation Organization’s All Weather Operations Panel.

[ICAO, 1999] International Civil Aviation Organization, 1999, Manual of Technical Provisions for the 

Aeronautical Telecommunication Network (ATN), ICAO Doc. 9705-AN/956 2nd Edition. 

[Ivanescu et al., 2004] Ivanescu, D., Powell, D., Shaw, C., Hoffman, E., and Zeghal, K., 2004, Effect of 

Aircraft Self-Merging in Sequence on an Airborne Collision Avoidance System, AIAA Guidance, 

Navigation, and Control Conference and Exhibit, AIAA 2004-4994. 

[JPDO, 2004] Joint Planning & Development Office, December 2004, Next Generation Air 

Transportation System Integrated Plan, Technical Report Version 1. 

[JPDO, 2007] Joint Planning and Development Office, August 2007, Next Generation Air 

Transportation System Research and Development Plan FY2009 – FY 2013, Draft Version 5. 

[JPDO, 2010] Joint Planning & Development Office, 2010, Concept of Operations for the Next 

Generation Air Transportation System, Version 3.2. 

[Jones, 2002] Jones, Denise R., 2002, Runway Incursion Prevention System Simulation Evaluation, 

Proceedings of the AIAA/IEEE 21st Digital Avionics Systems Conference. 

[Jones, 2005] Jones, Denise R., 2005, Runway Incursion Prevention System Testing at the Wallops Flight 

Facility, Proceedings of the SPIE Defense & Security Symposium. 

[Jones et al., 2001] Jones, D. R., Quach, C. C., and Young, S. D., 2001, Runway Incursion Prevention 

System – Demonstration and Testing at the Dallas/Fort Worth International Airport, Proceedings 

of the 20th Digital Avionics Systems Conference. 

32
[Jones et al., 2009] Jones, D. R., Prinzel, L. J., Otero, S. D., and Barker, G. D., 2009, Collision Avoidance 

for Airport Traffic Concept Evaluation, Proceedings of the AIAA/IEEE 28th Digital Avionics 

Systems Conference. 

[Jones et al., 2010] Jones, D. R., Prinzel, L. J., Shelton, K. J., Bailey, R. E., Otero, S. D., and Barker, G. 

D., 2010, Collision Avoidance for Airport Traffic Simulation Evaluation, Proceedings of the 

AIAA/IEEE 29th Digital Avionics Systems Conference. 

[Jones and Prinzel, 2006] Jones, Denise R., and Prinzel, Lawrence J., III, 2006, Runway Incursion 

Prevention for General Aviation Operations, Proceedings of the 25th Digital Avionics Systems 

Conference. 

[Jones and Young, 1998] Jones, Denise R., and Young, Steven, D., 1998, Flight Demonstration of 

Integrated Airport Surface Movement Technologies, NASA TM-1998-206283. 

[NTSB, 2000] National Transportation Safety Board, July 2000, Safety Recommendation, Letter to the 

FAA Administrator, A-00-66. 

[NTSB, 2011] National Transportation Safety Board, June 2011, NTSB Most Wanted List Transportation 

Safety Improvements, <www.ntsb.gov/safety/mwl.html>. 

[Parrish et al., 2006] Parrish, Russell V., Williams, Steve P., Arthur, Jarvis J., III, Kramer, Lynda J., 

Bailey, Randall E., Prinzel, Lawrence J., III, 2006, A Description of the “Crow’s Foot” Tunnel 

Concept, NASA/TM-2006-214311. 

[Prinzel et al, 2009] Prinzel, L. J., Jones, D. R., Shelton, K. J., Arthur, J. J., Bailey, R. E., Allamandola, 

A. S., Foyle, D. C., and Hooey, B. L., 2009, Flight Deck Display Technologies for 4DT and 

Surface Equivalent Visual Operations, Proceedings of the 15th International Symposium on 

Aviation Psychology. 

[Pritchett et al., 1995] Pritchett, A., Carpenter, B., Asari, K., Kuchar, J., and Hansman, R.J., 1995, Issues 

in Airborne Systems for Closely-Spaced Parallel Runway Operations, Proceedings of the 

AIAA/IEEE 14th Digital Avionics Systems Conference. 

[RTCA, 1993] RTCA, 1993, Minimum Operational Performance Standards for ATC Two-Way Data 

Link Communications, RTCA DO-219. 

[RTCA, 2002] RTCA, 2002, Minimum Aviation System Performance Standards (MASPS) for Automatic 

Dependent Surveillance Broadcast (ADS-B), RTCA DO-242A. 

[RTCA, 2007] RTCA, 2007, Minimum Aviation System Performance Standards (MASPS) for Traffic 

Information Service – Broadcast (TIS-B), RTCA DO-286B. 

[RTCA, 2009] RTCA, 2009, Minimum Operational Performance Standards for 1090 MHz Extended 

Squitter Automatic Dependent Surveillance - Broadcast (ADS-B) and Traffic Information 

Services – Broadcast (TIS-B), RTCA DO-260B. 

[RTCA, 2010] RTCA, June 2010, Terms of Reference Special Committee (SC) 147, Traffic Alert and 

Collision Avoidance System, Revison 9, RTCA Paper No. 113-10/PMC-800. 

33
[RTCA, 2010a] RTCA, April 2010, RTCA Program Highlights, RTCA Digest, No. 194. 

[RTCA, 2010b] RTCA, 2010, Safety, Performance, and Interoperability Requirements Document for 

Enhanced Traffic Situational Awareness on the Airport Surface with Indications and Alerts 

(SURF IA), RTCA DO-323. 

[Shelton et al., 2009] Shelton, K. J.; Prinzel, L. J.; Jones, D. R.; Arthur, J. J.; Allamandola, A. S.; and 

Bailey, R. E., 2009, Surface Map Traffic Intent Displays and Net-Centric Data-Link 

communications for NextGen, Proceedings of the 28th Digital Avionics Systems Conference. 

[Williams et al., 2006] Williams, J. L., Hooey, B. L., and Foyle, D. C., 2006, 4-D Taxi Clearances: 

Pilot’s Usage of Time- and Speed-based Formats, Proceedings of the AIAA Modeling and 

Simulation Technologies Conference. 

[Young, 1998] Young, Steven D., 1998, Comparison of A-SMGCS Requirements with Observed 

Performance of an Integrated Airport CNS System, Proceedings of the 17th Digital Avionics 

Systems Conference. 

34
Appendix A – RSM Operational States 

The ownship (O) and traffic (T) operational states used by RSM are defined as follows: 

taxi state: Aircraft/vehicles taxiing or stopped and stationary obstacles or equipment. 

pre-takeoff state: Ownship positioned for takeoff but before or at the beginning of takeoff roll. 

(This state is not available for traffic.) 

takeoff roll state: Ground takeoff roll in progress, not airborne. 

climb-out state: Airborne climb out after takeoff roll or after an aborted landing. 

approach state: Airborne on final approach. 

rollout state: Ground roll out after landing or after an aborted takeoff. 

fly-thru state: Flying through or crossing the RI zone but not landing or taking off. Includes 

turning from the runway heading during departure climb out or go-around 

The operational states are determined using the criteria described in the tables below. Table A1 

describes the criteria used to determine ownship operational states, supplemented by the ownship takeoff 

mode criteria described in Table A2. Table A3 describes the criteria used to determine traffic operational 

states. Table A4 details how the criteria from Tables A1 and A3 are used to define each operational state. 

The threshold parameters listed in these tables are customizable via configuration files. The ownship 

parameters can be configured differently for each type of ownship aircraft, while the traffic parameters 

are applied generically to all traffic aircraft. The threshold values listed under “Default Thresholds” 

should be considered examples, and can be adjusted as necessary. The general aviation thresholds under 

“GA” are untested estimates, and are expected to be refined based on future simulation and flight testing. 

Table A1. Ownship Operational State Criteria & Default Thresholds 

Operational State Criteria – Ownship

Code Description *

Default Threshold

GA** Non-GA

A Altitude above ground level (ft) <= 0 NA NA

B All wheels on the ground (true/false) NA NA

C Ground speed <= taxi high speed (knots) 20 40

D Aircraft is on the runway NA NA

E True heading differs from runway zone true heading <= heading 

tolerance (degrees)

10 10

F In takeoff mode (true/false), from Table A2:

F1 or (F2 and F7) or ((F3 or F4) and F5) or (C and F8) or ((not C) and F6)

NA NA

G Vertical speed > minimum climb-out vertical speed (ft/min) 60 60

H Distance from ownship position to end of runway >= approximate land 

rollout distance for type of landing (ft) (able to stop before end of 

runway)

2000 6000

* Text in bold indicates parameters specified under “Default Threshold”.

** GA thresholds have not been verified through testing. 

35
Table A2. Ownship Takeoff Mode Criteria & Default Thresholds 

Takeoff Mode Criteria – Ownship

Code Description *

Default Threshold

GA** Non-GA

F1 EPR mode set (true/false) NA NA

F2 Auto throttle engaged (true/false) NA NA

F3 Throttle position >= takeoff throttle position (degrees)(non-GA) - 90

F4 Throttle position is at full forward GA NA -

F5 Track acceleration > 0.0G NA NA

F6 Track acceleration >= 0.1G NA NA

F7 Track acceleration > 0.1G NA NA

F8 Track acceleration >= takeoff acceleration (G) 0.2 0.2

Table A3. Traffic Operational State Criteria & Default Thresholds 

Operational State Criteria – Traffic

Code Description *

Default Threshold

GA** Non-GA

I Altitude above ground level (ft) <= 0 NA NA

J Aircraft is on the runway NA NA

K True heading differs from runway zone true heading <= heading 

tolerance (degrees)

10 10

L Ground speed <= taxi high speed (knots) 20 40

M Ground speed >= taxi low speed (knots) 4 4

N Ground speed > minimum start takeoff speed for traffic (knots) 15 15

O Acceleration >= minimum start takeoff acceleration for traffic 

(knots/sec)

3 3

P Acceleration > minimum takeoff acceleration for traffic 

(knots/sec)

0.1 0.1

Q Vertical speed > minimum climb-out vertical speed for traffic 

(ft/min)

60 60

R Distance from traffic position to end of runway >= maximum 

traffic rollout distance (ft) (able to stop before end of runway)

2000 6000

36
Table A4. Operational State Definitions 

Operational State Ownship Criteria Traffic Criteria

taxi/stationary

(on or near 

runway)

A and B and C and 

((not D) or (not E) or (not F))

I and L and M and J and K and 

((not N) or (not O))

I and L and M and ((not J) or (not K))

I and L and (not M)

A and B and 

(not C) and ((not D) or (not E))

I and (not L) and ((not J) or (not K))

pre-takeoff A and B and C and D and E and F NA

takeoff roll A and B and (not C) and D and E and F I and L and M and J and K and N and O

I and (not L) and J and K and P

climb-out ((not A) or (not B)) and E and G (not L) and K and Q

((not A) or (not B)) and E and 

(not G) and (not H)

(not L) and K and (not Q) and (not R)

approach ((not A) or (not B)) and E and 

(not G) and H

(not L) and K and (not Q) and R

rollout A and B and (not C) and D and E and 

(not F)

I and (not L) and J and K and (not P)

fly-thru RI zone ((not A) or (not B)) and (not E) (not L) and (not K)

37
Appendix B – RSM Scenarios and Alert Criteria 

This appendix describes in detail the scenarios, alert criteria, and thresholds used by RSM to issue 

caution alerts and warning alerts (see Sections 3.1.1 and 3.1.2). The alert criteria and default thresholds 

are listed separately for conflicts on single runways (Table B1) and conflicts on intersecting runways or 

intersecting flight paths (Table B2). An intersecting flight path occurs when runway incursion (RI) zones 

intersect before or beyond the runway boundary (see Section 3.3). The default thresholds for alert criteria 

are implemented as parameters that are contained in software configuration files. The default values for 

warning thresholds were determined through simulation and flight testing, but can be modified as 

required based on future research. The default values for caution thresholds have undergone simulation 

evaluation, but are subject to change based on future research and testing. Previous testing [Jones, 2002 

and Jones and Prinzel, 2006] revealed that cautions were only effective/desirable when the ownship was 

in the approach state, or when the ownship was in position and hold and the traffic was approaching the 

same runway. Therefore, cautions are only implemented for two types of scenarios: (i) ownship state is 

approach, or (ii) ownship state is taxi or pre-takeoff, and traffic state is approach. 

For RSM criteria which specify a distance threshold, the distance is measured from the aircraft center 

of gravity (CG). Distance between ownship and traffic is measured from the ownship CG to the traffic 

CG.

The tables B3 – B9 define the scenarios for each combination of ownship and traffic states for both 

single and intersecting runway/flight path conditions and list the alert criteria associated with each 

scenario from the appropriate criteria table (B1 or B2). RSM detects and issues alerts for runway 

conflicts only when both the ownship aircraft and traffic are inside RI zones and below the zone altitude. 

For single runway scenarios, traffic is defined as other aircraft, vehicles, obstacles or equipment inside the 

same RI zone as the ownship aircraft. For intersecting zone scenarios, traffic is defined as other aircraft 

departing, arriving, or taxiing inside the RI zone that intersects the ownship RI zone. Traffic position and 

other traffic data must be available via data link to the ownship aircraft (see Section 4.2). 

38
Table B1. Alert Criteria & Default Thresholds for Single Runway Scenarios 

Alert Criteria – Single Runway Scenarios

(Assumes Ownship and Traffic are inside the same runway incursion zone)

Code Description *

Default Threshold

GA Non-GA

CA** WA+ CA** WA+

A Alert immediately at any distance NA NA NA NA

B O/T < minimum horizontal separation threshold (ft) 6000 4500 8000 6000

C O/T < close horizontal separation (ft) (lower separation 

threshold for some scenarios)

** 700 ** 700

D Distance from runway threshold of aircraft taxiing or stopped on 

runway is < approximate land rollout distance for type of landing 

aircraft (ft)

2000 2000 6000 6000

E Aircraft rolling out not able to stop before aircraft taxiing or 

stopped on runway

** NA ** NA

Fa Ownship distance to runway threshold or traffic position < 

airborne approach alert distance (ft)

(airborne alert distance based on approximate ownship landing 

speed, e.g., B-757 4400 ft for warning, 8000 ft for caution)

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Fc Ownship distance to runway threshold or traffic position < 

airborne climb-out alert distance (ft)

(airborne alert distance based on approximate ownship climbing

speed, e.g., B-757 6000 ft for warning, 8000 ft for caution)

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

G Stationary aircraft time to exit runway < alert time threshold 

(sec)

NA 30 NA 30

H Ownship distance to traffic position < 2.0 times the minimum 

horizontal separation threshold (ft)

(increased horizontal separation required for some scenarios)

12000 9000 16000 12000

I Arriving aircraft past the runway threshold NA NA NA NA

J O/T current or projected closest altitude separation < minimum 

air-to-air altitude separation (ft)

1000 850 1000 850

K O/T current or projected closest vertical separation < minimum 

air-to-ground vertical separation when one aircraft is on the 

ground (ft)

** 400 ** 400

* Text in bold indicates parameters specified under “Default Threshold”.

** Caution alert (CA) thresholds will only be applied for single runway scenarios of taxi/approach, pretakeoff/approach, or any ownship approach scenario. 

+ WA = warning alert 

39
Table B2. Alert Criteria & Default Thresholds for Intersecting Runway/Flight Path Scenario 

Alert Criteria – Intersecting Runway and Flight Path Scenarios

(Assumes Ownship and Traffic are inside intersecting RI zones and not past the zone intersection)

Code Description *

Default Threshold

GA Non-GA

CA** WA+ CA** WA+

L Alert immediately at any distance NA NA NA NA

M Current O/T difference in separation from intersection is < min 

separation threshold (ft)

6000 4500 8000 6000

N Current O/T difference in separation from intersection is < 0.5 

times the min separation (ft)

3000 2250 4000 3000

O Projected O/T closest separation at the intersection is < 

minimum separation threshold (ft)

6000 4500 8000 6000

P Projected O/T closest separation at the intersection is < 0.5 

times the min separation (ft)

3000 2250 4000 3000

Qa Ownship distance to runway threshold < airborne approach

alert distance (ft)

(airborne alert distance based on approximate ownship landing 

speed, e.g., B-757 4400 ft for warning, 8000 ft for caution)

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Ra Ownship distance to intersection < airborne approach alert 

distance (ft)

(airborne alert distance based on approximate ownship landing 

speed, e.g., B-757 4400 ft for warning, 8000 ft for caution)

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Rc Ownship distance to intersection < airborne climb-out

distance (ft)

(airborne alert distance based on approximate ownship climbing

speed, e.g., B-757 6000 ft for warning, 8000 ft for caution)

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

Per 

own 

landing 

speed

S Distance from touchdown to intersection for landing aircraft is <

approximate land rollout distance for type aircraft (ft)

2000 2000 6000 6000

T Aircraft rolling out is not able to stop before intersection NA NA NA NA

U Aircraft rolling out is < close distance to the intersection (ft) 700 700 700 700

V O/T current or projected closest air-to-air altitude separation is < 

minimum airborne altitude separation threshold (ft)

1000 850 1000 850

W O/T current or projected closest air-to-ground vertical separation 

is < minimum air-ground separation threshold (ft)

400 400 400 400

X O/T current or projected difference in separation from 

intersection is < close distance to the intersection (ft)

700 700 700 700

Y O/T current or projected difference in separation from

intersection is < 1.5 times the close distance to the 

intersection (ft)

1050 1050 1050 1050

* Text in bold indicates parameters specified under “Default Threshold”.

** Caution alert (CA) thresholds will only be applied for intersecting runway scenarios in which the ownship state is 

approach. 

+ WA = warning alert

40
Table B3. Scenario Conditions and Alert Criteria - Ownship in Taxi State 

Ownship (O) State – Taxi On or Near Runway (Inside RI zone)

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary Disabled for RSM scenarios

(Taxi conflicts are 

monitored by TCM)

__

Not defined for 

ownship taxi 

scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll O in path of T and closing A __ __

climb-out O Taxi / T Closing

O Stationary / T Closing

B and K

K

__ __

approach O/T Closing (B or G) and D

(warning)

D (caution)*

__ __

rollout O/T Closing (E or C) __ __

fly-thru RI zone Not defined; alerts not 

issued

__ __ __

* Criteria B and G are not applied for cautions in this scenario. 

41
Table B4. Scenario Conditions and Alert Criteria - Ownship in Pre-takeoff State 

Ownship (O) State – Pre-takeoff

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary T in path of O A Not defined for traffic taxi 

scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll T in path of O A Intersect before end of O 

runway

L

T behind O and closing A Intersect beyond end of O 

runway

N or O

climb-out O/T same heading & 

runway

B and K All conditions W and (N or 

O)

O/T head-on, opposite 

runways

K

approach O/T same heading & 

runway and T behind O

B or G

(warning)

A (caution)*

Intersect before end of O 

runway

S

O/T same heading & 

runway and T in path of O

B 

(warning)*

Intersect beyond end of O 

runway

__

O/T head-on, opposite 

runways

B or G

(warning)

A (caution)*

rollout T in path of O A Intersect before end of O 

runway

T or ((not T)

and U)

T behind O and closing B Intersect beyond end of O 

runway

__

fly-thru RI zone Closing or T in path of O C and K Not defined for traffic flythru scenarios__

* Criteria B and G are not applied for cautions in this scenario. 

42
Table B5. Scenario Conditions and Alert Criteria - Ownship in Takeoff roll State 

Ownship (O) State – Takeoff roll

Traffic (T) State

Single Runway Intersecting Runways and RI Zones

Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary

(on or near 

runway)

T in path of O and closing A Not defined for traffic taxi 

scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll O/T same heading & 

runway

B O able to abort takeoff and 

intersect before end of O 

runway

L

O able to abort takeoff and 

intersect beyond end of O 

runway

N or P

O/T head-on, opposite 

runways

A O not able to abort takeoff X

climb-out O/T same heading & 

runway

B O able to abort takeoff M or O

O/T head-on, opposite 

runways

A O not able to abort takeoff X

approach O/T same heading & 

runway and T behind O

B O able to abort takeoff and 

intersect before end of O 

runway

S

O/T same heading & 

runway and T in path of O 

A O not able to abort takeoff 

and intersect before end of 

O runway

S and Y

O/T head-on, opposite 

runways

A Intersect beyond end of O 

runway

__

rollout O/T same heading & 

runway and T in path of O

A O able to abort takeoff and 

intersect before end of O 

runway

T or

((not T) and U)

O/T same heading & 

runway and T behind O 

and closing

B O not able to abort takeoff 

and intersect before end of 

O runway

(T and Y) or

((not T) and U)

O/T head-on, opposite 

runways

A Intersect beyond end of O 

runway

__

fly-thru RI zone Closing or T in path of O C and K Not defined for traffic flythru scenarios__

43
Table B6. Scenario Conditions and Alert Criteria - Ownship in Climb-out State 

Ownship (O) State – Climb-out

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary O/T closing K and Fc Not defined for traffic 

taxi scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll O/T same heading & 

runway

B All conditions W and Rc

and (N or P)

O/T head-on, opposite 

runways

A

climb-out O/T same heading & 

runway

B All conditions Rc and

(N or P)

O/T head-on, opposite 

runways

(I or H)

approach O/T same heading & 

runway

B All conditions V and S and

Rc and

O/T head-on, opposite (N or P)

runways

J and (I or H)

rollout O/T same heading & 

runway and T in path of O

K and B All conditions W and

(N or P) and

Rc and

(T or U)

O/T same heading & 

runway and T behind O 

and closing

K and B

O/T head-on, opposite 

runways

K and (I or B)

fly-thru RI zone O/T closing or 

T in path of O

B Not defined for traffic 

fly-thru scenarios

__

44
Table B7. Scenario Conditions and Alert Criteria - Ownship in Approach State 

Ownship (O) State – Approach

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary Closing D and Fa Not defined for traffic 

taxi scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll O/T same heading & 

runway

B All conditions S and (N or P)

and

O/T head-on, opposite (Qa or Ra)

runways

A

climb-out O/T same heading & 

runway

B All conditions S and V and

P and

O/T head-on, opposite (Qa or Ra)

runways

J and (H or I)

approach O/T same heading & 

runway

B All conditions S and (N or P)

and

O/T head-on, opposite (Qa or Ra)

runways

(H or I)

rollout O/T same heading & 

runway

B All conditions S and (T or U)

and

O/T head-on, opposite (Qa or Ra)

runways

A

fly-thru RI zone O/T closing or 

T in path of O

B Not defined for traffic 

fly-thru scenarios

__

45
Table B8. Scenario Conditions and Alert Criteria - Ownship in Rollout State 

Ownship (O) State – Rollout

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary O/T closing E or C Not defined for 

traffic taxi scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll O/T same heading & 

runway and T ahead of O

B All conditions (T or U)

O/T same heading & 

runway and T behind O

A

O/T head-on and opposite 

runways

A

climb-out O/T same heading & 

runway and T behind O

K and B All conditions W and (M or 

O) and

O/T same heading & (T or U)

runway and T ahead of O

K and B

O/T head-on, opposite 

runways

K and (I or B)

approach O/T same heading & 

runway (T behind or 

ahead)

B All conditions S and (T or U)

O/T head-on, opposite 

runways

A

rollout O/T same heading & 

runway

B All conditions (T or U)

O/T head-on, opposite 

runways

A

fly-thru RI zone O/T closing or 

T in path of O

C and K Not defined for 

traffic fly-thru 

scenarios

__

46
Table B9. Scenario Conditions and Alert Criteria - Ownship in Fly-thru RI Zone State 

Ownship (O) State – Fly-thru RI Zone

 Single Runway Intersecting Runways and RI Zones

Traffic (T) State Scenario Conditions Alert Criteria Scenario Conditions Alert Criteria

taxi/stationary Incursion scenario not 

defined; alerts not issued

__ Not defined for ownship 

fly-thru scenarios

__

pre-takeoff NA (Traffic pre-takeoff 

state not avail in current 

version)

__ __ __

takeoff roll Closing or O in T path C and K __ __

climb-out Closing or O in T path B __ __

approach Closing or O in T path B __ __

rollout Closing or O in T path C and K __ __

fly-thru RI zone Incursion scenario not 

defined; alerts not issued

__ __ __

47
Appendix C – RSM Scenarios and SURF IA Indication Criteria 

In parallel with CAAT, the RTCA SC-186 WG1 subcommittee for surface indication and alerting 

(SURF IA) has defined criteria to determine whether a potential conflict exists between an ownship and 

traffic aircraft [RTCA, 2010b]. SURF IA is only concerned with runway scenarios, and is not relevant to 

low altitude or taxi scenarios. Similar to CAAT, SURF IA identifies operational states for each aircraft. 

Resembling CAAT, for each possible combination of ownship state and traffic state, SURF IA defines a 

set of criteria to determine whether an alert should be issued. SURF IA also classifies alerts to be either 

Cautions or Warnings, as does ATCAM. SURF IA defines alerts for "non-normal operational situations 

where collision hazard exists or a collision appears imminent". ATCAM does not implement alerts as 

defined by SURF IA, but instead uses the RSM algorithm defined previously. 

In addition to alerts, SURF IA also specifies indications, which are defined for "normal operational 

situations where collision hazard exists". In other words, indications are less serious than alerts. SURF 

IA classifies indications to be either Traffic Indications (TI) or Runway Status Indications (RSI). 

RSM has been extended to implement SURF IA indications. RSM operational states are converted 

into SURF IA states, as defined in Table A-1 of reference RTCA 2010b. This conversion is described in 

Table C1 below. RSM will issue indications prior to alerts if the criteria in Table A-2 of reference RTCA 

2010b are met. However, alerts have priority over indications and will be issued instead of indications if 

the alert criteria is met. 

Table C1. ATCAM-to-SURF IA State Mapping 

ATCAM States Mapping Conditions SURF IA States

hold short* Stopped outside RI zone within 500 

ft. of centerline, facing runway

I. Taxiing on taxiway toward hold 

line or stopped at hold line

Taxiing outside RI zone beyond 

look-ahead distance, within 500 ft. 

of centerline, facing runway

taxi/stationary Outside RI zone, within look-ahead 

distance 

I. Taxiing on taxiway toward hold 

line or stopped at hold line

Inside RI zone, heading differs from 

runway heading by more than 10 

degrees

II. Entering / Crossing / Exiting

Inside RI zone, heading within 10 

degrees of runway heading

VI. Stopped or taxiing along runway

pre-takeoff VI. Stopped or taxiing along runway

takeoff roll III. Takeoff

climb-out 0. Unknown

approach IV. Approach

rollout V. After Landing

fly-thru 0. Unknown

* Hold short is a new RSM state, created to support SURF IA state I. A new state is necessary because 

RSM currently does not consider stationary aircraft at the hold line to be traffic; but such aircraft are 

candidates for indications. This state is only relevant when determining indications, and does not affect 

alert calculations. 

48
RSM can be expected to issue indications according to SURF IA specifications, except in the 

following cases: 

 If RSM issues an alert for a case in which SURF IA does not issue an alert, then RSM will not 

issue any SURF IA indications, because the alert takes precedence. 

 RSM will not classify an aircraft to be in approach state until it reaches the extended runway 

zone, and will not issue indications for that aircraft outside the extended zone. SURF IA defines 

the approach state to begin within three nautical miles, once the aircraft descends below one 

thousand feet. Consequently, SURF IA may issue approach indications earlier than RSM. 

49
Appendix D – Flight Data Requirements 

This appendix lists the flight data that is currently used by the ATCAM software. Table D1 lists the 

ownship data, while Table D2 lists the traffic data. Note that the throttle position or power lever angle is 

assumed to be available to indicate forward thrust (with thrust reverser data available as well) for a 

‘commercial transport aircraft’ (i.e., “non-GA”), whereas for general aviation aircraft, the throttle position 

ranging between 0 (full closed) and 1 (full open) is used to imply forward thrust (i.e., “GA”). 

Table D1. Ownship Data Parameters 

DESCRIPTION

BINARY 

RANGE UNITS

POSITIVE 

REFERENCE

MINIMUM

UPDATE 

RATE

Update counter NA Always positive 10 HZ

Standard time in GMT 0 to 86,400 Sec Seconds from midnight 10 HZ

Scaled GPS/INS blended latitude +/-90 Deg North from 0 10 HZ

Scaled GPS/INS blended long +/-180 Deg East from 0 10 HZ

GPS/INS blended altitude-feet MSL +/-32,768 Feet Above touchdown 10 HZ

Geoid separation corrected hybrid GPS 

altitude +/-32,768 Feet Above touchdown 10 HZ

Corrected barometric altitude - 4 sources +/-32,768 Feet Above sea level 10 HZ

Radar altitude +/-32,768 Feet Above touchdown 10 HZ

Ground speed 0 - 4096 Knots Always positive 10 HZ

Vertical speed +/-19,384 Ft/Min Up 10 HZ

True heading +/-180 Deg CW from North 10 HZ

Yaw rate +/-128 Deg/Sec Nose right 10 HZ

Track angle (true) +/-180 Deg CW from North 10 HZ

Along track acceleration +/-4 G's Forward 10 HZ

Throttle position/power lever angle – left 

(non-GA) +/-180 Deg Forward thrust 10 HZ

Throttle position/power lever angle – right 

(non-GA) +/-180 Deg Forward thrust 10 HZ

Throttle position (GA) Discrete NA 1 = Full open 10 HZ

Reverser isolation valves Discrete NA 1=Reverse thrust 10 HZ

Air ground discrete Discrete NA 1=Main gear on ground 10 HZ

Nose wheel squat Discrete NA 1=Nose wheel on ground 10 HZ

Go around discrete Discrete NA 1=Go around engaged 10 HZ

Auto-throttle engaged Discrete NA 1=Engaged 10 HZ

Decision speed 0-512 Knots Always positive 10 HZ

GPS hybrid position status Discretes NA 0=Good 10 HZ

50
Table D2. Traffic Data Parameters 

DESCRIPTION

BINARY 

RANGE UNITS

POSITIVE 

REFERENCE

UPDATE 

RATE

# Traffic/intruders 0-64 NA Always positive 1-2 HZ

Traffic update counter NA Always positive 1-2 HZ

24 bit ICAO address or unique intruder id 0-32 NA NA 1-2 HZ

Intruder flight or tail number Character field NA NA 1-2 HZ

A/C category (A380, B757, etc.) 0-7 NA NA 1-2 HZ

A/C type (if known) Character field NA NA 1-2 HZ

Latitude +/-90 Deg North from 0 1-2 HZ

Longitude +/-180 Deg East from 0 1-2 HZ

Altitude MSL +/-32,768 Feet Above mean sea level 1-2 HZ

Radar altimeter +/-32,768 Feet Above touchdown 1-2 HZ

Ground speed 0-32,768 Knots Always positive 1-2 HZ

True track (airborne) or heading (on ground) +/-180 Deg CW from North 1-2 HZ

Vertical speed +/-19,384 Ft/Min Up 1-2 HZ

Track acceleration +/-4 G’s Forward 1-2 HZ

Slant range NM Always positive 1-2 HZ

Bearing +/-180 Deg CW from ownship 1-2 HZ

Relative altitude +/-32768 Feet Above ownship 1-2 HZ

Traffic acquisition in msec GMT 0 to 86,400,000 Msec Always positive 1-2 HZ

51
Appendix E – Surveillance Discussion 

E.1 Surveillance Performance 

Requirements for ground-based surveillance systems have been proposed. As mentioned above, 

ICAO proposed operational requirements for A-SMGCS, which includes surveillance performance 

requirements [ICAO, 1997]. A prototype A-SMGCS architecture was evaluated during a flight test at the 

Atlanta Hartsfield International Airport [Jones and Young, 1998] and observed performance was 

compared against the A-SMGCS requirements [Young, 1998]. 

More recently, the European Organization for Civil Aviation Equipment (EUROCAE) has proposed 

surveillance performance requirements for a Level 2 A-SMGCS that will be expected to monitor the 

airport surface and provide alerts to users when hazardous situations occur, such as runway incursions 

[EUROCAE, 2007]. These requirements are listed in Table E1. 

The FAA is in the process of deploying ADS-B throughout the NAS. A final rule [FAA, 2010] has 

been enacted to specify ADS-B Out performance requirements necessary to support ATC service. 

Although the FAA is not mandating ADS-B In at this time, the final rule includes a discussion of 

potential ADS-B In applications and accuracy requirements. The Notice of Proposed Rulemaking 

(NPRM) [FAA, 2007] had proposed that a horizontal accuracy of 30 meters (98.4 feet) and a vertical 

accuracy of 45 meters (147.6 feet) would be sufficient to enable certain applications on the airport 

surface, such as traffic alerting, however, the final rule only requires a horizontal accuracy of 0.05 nm 

(92.6 meters or 303.8 feet) and has removed the vertical accuracy and integrity requirement. The RTCA 

SC-186 WG1 subcommittee for surface indication and alerting (SURF IA) has conducted analyses and 

requires a minimum of a Navigation Accuracy Category position (NACp) of 9 for the SURF IA 

application [RTCA, 2010b] (see Table E2), which corresponds to the position accuracy proposed in the 

NPRM. Unfortunately, the final rule requires position accuracy of traffic data corresponding to a NACp 

of 8, which may be insufficient for CD&R applications. More analysis is needed to determine whether 

these proposed accuracies are really sufficient for conflict detection. 

Table E1. EUROCAE A-SMGCS Surveillance Performance Requirements 

Performance Parameter Level 2 System Requirement

Probability of target detection ≥ 99.9% on maneuvering area

≥ 98% on apron

Probability of false target detection ≤ 10-3per report

Probability of identification ≥ 99.9% on maneuvering area

≥ 98% on apron

Probability of false identification ≤ 10-3per report

Reported position accuracy ≤ 7.5 meters (95%) on maneuvering area

≤12 meters (95%) on apron

Reported velocity accuracy Speed < 5 meters/second, Direction –

consistent with use in alerting algorithms

Target report update rate At least 1 per second

Position renewal time out period < 4 seconds

Identification renewal time out period < 20 seconds

Track continuity ≥ 99.8% on maneuvering area

≥ 98% on apron

Target report position resolution ≤1 meter

Target report velocity resolution ≤0.25 meter/second

Target report time resolution ≤ 0.1 second

52
Table E2. SURF IA Surveillance Performance Requirements 

Performance Parameter Requirement

Traffic horizontal position accuracy Distance from runway

Shoulder to hold line (m) NACp

 20 – 25 11

 30 – 60 10

 65 – 100 9

95% containment radius

Ownship and traffic geometric altitude 45m, 95%

Ownship and traffic velocity 10 m per second

Vehicle horizontal position accuracy 10 m, 95% containment

Ownship and traffic integrity level Indication – 1 x 10-4 per hour

Caution - 1 x 10-4 per hour

Warning - 1 x 10-5 per hour

E.2 Intent Data 

ADS-B provides a minimal set of data for airport traffic. Historically, the RSM algorithm has had 

good results in computing traffic states, utilizing the currently available data from ADS-B, however, 

knowledge of traffic intent could potentially provide a more accurate assessment of traffic state and result 

in more precise conflict detection with reduced missed, and nuisance alerts. Some intent data currently 

specified for ADS-B involve intent to change trajectory at a particular position. However, the type of 

intent data that may improve the performance of the conflict detection function in the ATMA is related to 

operations on or near the airport surface. 

Ownship states can be computed accurately because the data to indicate “intent” to takeoff, “intent” 

to land, etc., is available from the ship’s flight computers. Some examples of these data sources might 

include: 

 Takeoff intent - on the runway, lined up with runway heading and Engine Pressure Ratio (EPR) 

button or Auto-throttle button pushed, throttle position. 

 Intent to land – Auto-land engaged, lined up with runway and descending, ILS tuned and aircraft 

following localizer and glideslope, landing configuration and airspeed. 

However, these intent data are not available for traffic. With the increase in capacity envisioned by 

NextGen, traffic will be more densely spaced making the need for knowledge of traffic intent even more 

critical. 

The following traffic intent data/information could potentially enable more effective, timely, and 

error free CD&R in the ATMA. More analysis is necessary to determine the potential benefits of utilizing 

this data/information. 

 Takeoff mode – Determining when traffic is actually taking off can currently be determined by 

monitoring ground speed. Knowing that the pilot has taken the runway and has engaged the EPR 

mode or Auto throttle mode, for example, would indicate takeoff intent as well as knowing throttle 

position (advanced full forward) in lesser equipped aircraft. 

 

 Go Around mode – Knowing when traffic is aborting a landing can currently be determined by 

noting that the aircraft is climbing and accelerating. A more timely means would be to transmit 

53
when the go around is initiated (go around button pressed or throttles advanced and aircraft 

configured for climbing). 

 Rejected Takeoff mode – Knowing when an aircraft aborts takeoff can eventually be determined by 

observing the traffic’s greatly reduced speed and either stopping on or exiting the runway. The 

ability to know if the power goes to idle (throttle position), brakes are pressed and/or thrust 

reversers are used could result in a more effective means of determining if a rejected takeoff 

occurred. 

 Land and Hold Short Operations (LAHSO) – Knowing intent to follow LAHSO operations at 

airports like ORD might prevent nuisance runway incursion alerts in an intersecting runway 

situation. The logic would be similar to the rejected takeoff criteria above for determining intent to 

stop. Knowledge of intent to LAHSO could be obtained via pilot entry or, in the absence of such an 

entry, via broadcast of ATC instructions (see below). 

 Termination of taxi – Knowing that the traffic that could become a conflict is aware and braking 

might allow the CD&R algorithms to delay alerting to prevent nuisance alerts in cases where the 

errant traffic’s nose barely passed the hold short line or the errant traffic could stop before 

becoming dangerously close to another aircraft on the surface. 

 Air-ground – Knowing whether traffic is in the air or on the ground is critical for ATMA CD&R. 

Airborne ADS-B messages are needed for runway and low altitude CD&R because the message 

contains altitude data. When an aircraft is determined to be on the ground, ADS-B transmissions 

will contain surface message content (with no altitude data) instead of airborne message content. If 

surface ADS-B messages are transmitted prematurely, runway and low altitude CD&R could be 

affected. Since surface position messages are transmitted less frequently than airborne position 

messages, valuable position data required when the aircraft is indeed airborne with a rapid closure 

rate is unavailable, possibly leading to an avoidable collision. It is not clear that the current method 

of switching between airborne and surface ADS-B messages will be sufficient for ATMA CD&R. 

Aircraft with air-ground detection would switch at the proper time. All others would switch based 

on the presence or absence of airspeed, ground speed, and radar altitude which will either cause an 

early or delayed switch between airborne position messages and surface position messages. 

Knowing precisely when traffic is on the ground based on weight on wheels or nose wheel squat 

could potentially resolve this ambiguity. 

 Air Traffic Control Instructions – Knowledge of other traffic’s clearances (e.g., “cleared for 

takeoff”, cleared to land”, “land and hold short”) for operations in the ATMA could potentially 

increase safety and prevent conflicts and collisions through awareness of the intentions of other 

traffic. Awareness of traffic’s intended taxi path and hold short clearances may also reduce 

conflicts at taxiway and runway intersections. Taxi awareness and conflict prevention/detection 

can be further refined in the NextGen environment with knowledge of traffic’s 4-D taxi path and 

required times of arrival at intersections. 

E.3 ADS-B Altitude Data 

An area of concern for CD&R in the ATMA is the granularity of all ADS-B reported altitudes. The 

source for ADS-B altitude is currently either Global Navigation Satellite System (GNSS) or barometric 

altitude reported to the nearest 100 feet or 25 feet [RTCA, 2009]. These accuracies are sufficient for 

aircraft that are airborne and not near the surface (above 1000 feet AGL). However, since altitude 

54
changes rapidly during takeoff and departure, these accuracies may not be good enough for the current 

implementation of an algorithm such as ATMA CD&R. The current implementation uses three separate 

algorithms with very different capabilities operating to cover all flight realms and altitude is a key trigger 

for switching between the algorithms. This issue has not, at this time, been rigorously evaluated. 

Sources of error for barometric altitude reporting include instrument calibration, rounding altitude to 

the nearest 25 + 12.5 feet or 100 feet + 50 feet, and incorrect barometric pressure setting. An incorrect 

setting of 0.5 inches Mercury could cause the altitude report to be 500 feet higher or lower than the actual 

barometric altitude. GNSS position data also has the greatest error in its vertical measurements, i.e., the 

height above the ellipsoid. As a result, aircraft could be mistaken for being on the ground while airborne 

or vice versa, which could cause CD&R algorithms, such as ATCAM, to incorrectly determine the traffic 

operational states. (See Section 5.4.4). Further testing is needed to determine the effects of altitude 

variance on CD&R algorithms, and in what ways algorithms need to account for such variance. 

ADS-B altitude accuracy could be improved if radio altitude were used in lieu of GNSS or barometric 

altitude when the aircraft is within 1000 feet of the airport surface. Many radar altitudes provide radio 

altitude accuracy to within 2 feet. (Unfortunately, radar altitude is not required on most aircraft.) 

Barometric and GNSS altitudes are encoded to the nearest 25 feet or 100 feet within the airborne position 

message format to conserve the number of bits utilized in data transmission while still providing suitable 

altitude accuracy at the higher altitudes. Since the range of values for the radio altitude are capped, 

usually to 2500 feet, the space allocated within the ADS-B airborne message format can represent the 

radio altitude to the nearest foot. Using radio altitude in lieu of GNSS or barometric altitude to represent 

a much more accurate value for altitude AGL, would enable ATMA CD&R algorithms to make more 

accurate aircraft state decisions. 

Another area of concern is the transition between ADS-B airborne and surface messages (see 

previous section). Radio altitude is used as the criteria to switch between airborne and surface messages. 

Aircraft with a radio altitude of 50 feet or less are considered to be on the ground when ground speed is 

100 knots or less [RTCA, 2009]. Since ADS-B surface position messages do not include altitude, the 

transition to surface messages at 50 feet AGL or greater due to the errors mentioned above would cause 

the loss of altitude reports before touchdown, which could cause nuisance CD&R alerts. Using alternate 

criteria, such as weight-on-wheels or nose wheel squat for those aircraft that provide that information, 

would ensure the switch to surface position message transmission would occur when the aircraft is on the 

ground.

Further research is needed to determine the effect of ADS-B altitude accuracy and surface message 

reporting on ATMA CD&R. 

55
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

Technical Memorandum

 4. TITLE AND SUBTITLE

Initial Concept for Terminal Area Conflict Detection, Alerting, and 

Resolution Capability On or Near the Airport Surface, Version 2.0 

5a. CONTRACT NUMBER

 6. AUTHOR(S)

Otero, Sharon D.; Barker, Glover D.; Jones, Denise, R.

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

NASA Langley Research Center

Hampton, VA 23681-2199

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

National Aeronautics and Space Administration

Washington, DC 20546-0001

 8. PERFORMING ORGANIZATION

 REPORT NUMBER

L-20272

10. SPONSOR/MONITOR'S ACRONYM(S)

NASA

13. SUPPLEMENTARY NOTES

Sharon Otero, Lockheed Mission Services, Hampton, VA (currently with Northrop Grumman, Hampton, VA); Glover Barker, Lockheed Mission Services, Hampton, VA (currently with Science Systems and Applications, Inc., Hampton, VA); Denise Jones, NASA Langley Research Center, Hampton, VA

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

The Next Generation Air Transportation System (NextGen) concept for 2025 envisions the movement of large numbers of people and goods in a safe, efficient, 

and reliable manner. The NextGen will remove many of the constraints in the current air transportation system, support a wider range of operations, and deliver 

an overall system capacity up to 3 times that of current operating levels. In order to achieve the NextGen vision, research is necessary in the areas of surface 

traffic optimization, maximum runway capacity, reduced runway occupancy time, simultaneous single runway operations, and terminal area conflict 

prevention, among others. The National Aeronautics and Space Administration (NASA) is conducting Collision Avoidance for Airport Traffic (CAAT) 

research to develop technologies, data, and guidelines to enable Conflict Detection and Resolution (CD&R) in the Airport Terminal Maneuvering Area 

(ATMA) under current and emerging NextGen operating concepts. The term ATMA was created to reflect the fact that the CD&R concept area of operation is 

focused near the airport within the terminal maneuvering area. In this report, an initial concept for an aircraft-based method for CD&R in the ATMA is 

presented. This method is based upon previous NASA work in CD&R for runway incursion prevention, the Runway Incursion Prevention System (RIPS). 

15. SUBJECT TERMS

Air traffic; Air transportation; Collision avoidance; Runway incursions; Runways

18. NUMBER

 OF 

 PAGES

62

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.73.07.01

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

NASA/TM-2013-218052

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- 10 - 2013