February 2006 

NASA/CR-2006-214275 

Runway Safety Monitor Algorithm for Single 

and Crossing Runway Incursion Detection and 

Alerting 

David F. Green, Jr. 

Lockheed Martin Corporation, Langley Program Office, Hampton, Virginia 
The NASA STI Program Office . . . 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 Office plays a key part in helping NASA 

maintain this important role. 

The NASA STI Program Office is operated by 

Langley Research Center, the lead center for NASA’s 

scientific and technical information. The NASA STI 

Program Office provides access to the NASA STI 

Database, the largest collection of aeronautical and 

space science STI in the world. The Program Office is 

also NASA’s institutional mechanism for 

disseminating the results of its research and 

development activities. These results are published 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 co-sponsored 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. Englishlanguage translations of foreign scientific and 

technical material pertinent to NASA’s mission. 

Specialized services that complement the STI 

Program Office’s diverse offerings include creating 

custom thesauri, building customized databases, 

organizing and publishing research results ... even 

providing videos. 

For more information about the NASA STI Program 

Office, see the following: 

• Access the NASA STI Program Home Page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to 

help@sti.nasa.gov 

• Fax your question to the NASA STI Help Desk 

at (301) 621-0134 

• Phone the NASA STI Help Desk at 

(301) 621-0390 

• Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7121 Standard Drive 

 Hanover, MD 21076-1320
National Aeronautics and 

Space Administration 

Langley Research Center Prepared for Langley Research Center 

Hampton, Virginia 23681-2199 under Contract NAS1-00135B

 

February 2006 

NASA/CR-2006-214275 

Runway Safety Monitor Algorithm for Single 

and Crossing Runway Incursion Detection and 

Alerting 

David F. Green, Jr. 

Lockheed Martin Corporation, Langley Program Office, Hampton, Virginia 
Available from: 

NASA Center for AeroSpace Information (CASI) National Technical Information Service (NTIS) 

7121 Standard Drive 5285 Port Royal Road 

Hanover, MD 21076-1320 Springfield, VA 22161-2171 

(301) 621-0390 (703) 605-6000 
ERRATA 

NASA/CR-2006-214275 

Runway Safety Monitor Algorithm for Single and Crossing Runway 

 Incursion Detection and Alerting 

David F. Green, Jr. 

February 2006 

Issue Date: 04/11/06 

The “B” was inadvertently omitted from the contract number on the title page and in 

Block 5a on the Report Documentation Page. The correct NASA Contract number is 

NAS1-00135B. 
1

Table of Contents 

1.0 INTRODUCTION..............................................................................................................................................3

2.0 GENERAL DESCRIPTION AND CAPABILITIES ......................................................................................4

2.1 Incursion Detection and Alerting...................................................................................................................4

2.2 Runway Incursion Zones ................................................................................................................................5

2.3 Incursion Scenarios.........................................................................................................................................6

3.0 THE RSM ALGORITHM – TECHNICAL APPROACH .............................................................................7

3.1 General Description ...............................................................................................................................7

3.1.1 Operational States and Operational State Matrices...............................................................................7

3.1.2 Software Design .....................................................................................................................................8

3.1.3 Interfacing With RIPS Software .............................................................................................................8

3.1.4 Criteria and Parameters.........................................................................................................................9

3.2 Logic and Data Flow ..............................................................................................................................9

3.2.1 Component 1: RSM Main .......................................................................................................................9

3.2.1.1 Traffic Data Function..................................................................................................................9

3.2.1.2 Ownship Data Function ...........................................................................................................10

3.2.1.3 Alert Data Output Function......................................................................................................10

3.2.2 Component 2: Setup and Testing Status - Start/Stop/Continue Conflict Testing.................................10

3.2.3 Component 3: Single Runway Conflicts...............................................................................................11

3.2.3.1 Monitoring Traffic in the Ownship Zone ................................................................................11

3.2.3.1.1 Computing and Smoothing Traffic Data....................................................................................11

3.2.3.1.2 Determining the Traffic Operational State.................................................................................12

3.2.3.2 Detecting Conflicts in the Ownship Zone..............................................................................12

3.2.3.2.1 Applying Operational State Matrix & Alert Criteria for Single Runways.................................12

3.2.3.2.2 Aging Conflict Alerts ................................................................................................................15

3.2.4 Component 4: Crossing Runway and Intersecting Flight Path Conflicts.............................................15

3.2.4.1 Detecting Conflicts in the Crossing Zones............................................................................16

3.2.4.1.1 Applying Operational State Matrix & Alert Criteria for Crossing Zones..................................16

3.2.4.1.2 Land And Hold Short Operations ..............................................................................................18

3.2.5 Component 5: Processing Conflict Alert Data.....................................................................................18

4.0 RSM PERFORMANCE RESULTS ..............................................................................................................19

4.1 Incursion Scenario 1 – Crossing Runway ............................................................................................19

4.2 Incursion Scenario 2 – Crossing Runway.............................................................................................20

4.3 Incursion Scenario 3 – Crossing Runway.............................................................................................20

4.4 Incursion Scenario 4 – Crossing Runway.............................................................................................21

4.5 Incursion Scenario 5 – Single Runway .................................................................................................22

4.6 Incursion Scenario 6 – Single Runway .................................................................................................23

4.7 Incursion Scenario 7 – Single Runway .................................................................................................24

4.8 Performance Summary .........................................................................................................................25

4.9 Future Research and Development .......................................................................................................25

ACKNOWLEDGMENTS .....................................................................................................................................27

REFERENCES.......................................................................................................................................................27
2

FIGURES..................................................................................................28 

TABLES...................................................................................................39 
3

RUNWAY SAFETY MONITOR 

Algorithm for Single and Crossing Runway 

Incursion Detection and Alerting 

1.0 INTRODUCTION 

The Runway Safety Monitor (RSM) was developed by Lockheed Martin in support of 

NASA’s Runway Incursion Prevention System (RIPS) research. This work was conducted 

under the NASA Aviation Safety and Security Program’s Synthetic Vision System project. 

The National Transportation Safety Board (NTSB) has, for a number of years, listed 

runway incursions on its most wanted list of transportation safety improvements in 

aviation. The NTSB has made a recommendation to stop runway incursions/ground 

collisions of aircraft and give immediate warnings of these events directly to flight crews in 

the cockpit [1]. The NTSB recommendation is consistent with the goal of NASA RIPS 

research to investigate technology and generate requirements for an aircraft based system 

than can eliminate runway incursions. 

RSM is an important step in realizing the NASA RIPS research goal. The RSM algorithm 

is a software package that runs on the aircraft to detect hazardous situations that cause 

runway incursions as early as possible and alert the flight crew in time to take necessary 

corrective or evasive action. RSM is a component of the overall RIPS research software 

that also includes advanced data communications, real-time graphics displays and aural 

warnings to provide pilots with enhanced situational awareness. The possibility of runway 

incursions is greatly reduced by RIPS software capabilities and displays including an 

electronic moving map (EMM) display, a heads up display (HUD), a primary flight display 

(PFD), cockpit display of traffic information (CDTI), taxi routing, air traffic control (ATC) 

instructions, aural alerts for off taxi route and crossing hold, and other features that increase 

the pilot’s situational awareness. Results of flight testing verify that incursions are less 

likely to occur when these RIPS capabilities are employed on aircraft. However, in the 

event an incursion is in progress or about to occur, incursion detection and aural/graphical 

alerting by RSM on board the aircraft allows evasive or corrective action to be taken 

immediately to reduce or eliminate the possibility of a serious accident. 

The Federal Aviation Administration (FAA) defines a runway incursion as “any occurrence 

in the airport runway environment involving an aircraft, vehicle, person, or object on the 

ground, that creates a collision hazard or results in a loss of required separation with an 

aircraft taking off, intending to take off, landing, or intending to land.” [2] The RSM is 

designed to detect and alert for the conditions specified in this definition. However, the 

definition is vague leaving many situations open for interpretation. The upgraded version 

of RSM uses the broader term, “runway conflict”, which encompasses the FAA definition 

of incursion but also includes other situations that could cause a collision hazard. This 

report defines a runway conflict as any occurrence including loss of separation that could 

result in a collision hazard on the runway or during any phase of take off or landing. This 

definition includes situations when both aircraft involved in the conflict are airborne such 
4

as on approach to crossing runways or intersecting approach flight paths. Runway conflict 

also includes situations that involve violations of ATC departure and arrival separation 

procedures. RSM is designed to detect and alert the flight crew to these situations. The 

specific runway conflicts detected by RSM are described in more detail in other sections of 

this report. 

RSM was flight tested on NASA’s B-757 research aircraft at the Dallas-Fort Worth 

International Airport (DFW) in October 2000. The description and performance of RSM 

for that flight test was documented in a NASA contractor report [3] and Digital Avionics 

Systems Conference paper [4]. During that flight test, RSM was tested successfully for a 

number of single runway incursion scenarios. Single runway incursion scenarios involve 

two aircraft using the same runway or one aircraft landing/taking off with an obstruction on 

the runway. Since the DFW flight test, RSM has been upgraded and enhanced to include 

incursion scenarios for crossing runways and intersecting flight paths as well as additional 

single runway scenarios that were not available for the DFW flight test. Many other new 

features and capabilities have been added, and the algorithm has also been converted to a 

standalone version that runs independently on UNIX and PC systems. The advanced 

version of RSM has been tested in a full mission piloted simulation conducted in March 

2002 [5]. In the summer of 2004 the algorithm was flight tested at the Reno/Tahoe 

International Airport (RNO) and the Wallops Flight Facility (WAL) during the GulfstreamV Integrated Technology Evaluation (GVSITE) flight test. This report supplements and 

updates the previous contractor report for the DFW flight test [3] and describes in detail the 

performance of RSM during the GVSITE flight test at Reno and Wallops. 

2.0 GENERAL DESCRIPTION AND CAPABILITIES 

2.1 Incursion Detection and Alerting 

The RSM is a standalone program designed to run on board an aircraft using data linked 

traffic information. It runs in conjunction with the RIPS software that provides the data 

communications as well as aural alerts and graphics displays needed for incursion alerting. 

RSM does not use detailed terrain or airport databases but does require highly accurate 

information for airport runways, and accurate real-time flight data for ownship and traffic 

on or near the airport. 

RSM detects a runway incursion and issues an alert when the ownship aircraft (e.g., 

Gulfstream-V used for GVSITE) is using a runway and there is a conflict with other traffic 

using the same runway, a crossing runway or an intersecting flight path. Other traffic is 

defined as aircraft, vehicles, equipment or objects that can be identified by one or more 

traffic data sources and data linked to the ownship aircraft. Traffic data sources used for 

GVSITE are described in Section 3.2.1.1. A conflict, as defined in Section 1.0, is any 

occurrence (including loss of separation) that results in a collision hazard on the runway or 

during any phase of take off or landing. RSM issues a Runway Conflict Alert (RCA) when 

a conflict situation is detected. An RCA is a warning that the potential for a collision exists 

and, therefore, an evasive maneuver should be initiated at the pilot’s discretion. Guidance 
5

for any specific evasive maneuver is not provided by the algorithm or the alerting system. 

RSM is a single stage alerting system (RCA’s only) and does not issue advisory or 

cautionary alerts before the situation becomes a conflict. An RCA can be triggered due to 

an error on the part of one or both aircraft/traffic involved, controller error, weather or 

other reasons. However, the RSM algorithm does not consider the cause of the conflict 

when issuing alerts. The same alert is issued whether the conflict is the result of action by 

ownship, traffic, air traffic control or any other cause. 

2.2 Runway Incursion Zones 

A major concept of the RSM algorithm is the use of runway incursion zones. A runway 

incursion zone is a software-derived three-dimensional virtual zone that is not depicted on 

flight deck displays. There is one incursion zone for each runway on the airport that 

includes both ends of the runway. The horizontal dimensions of a runway incursion zone 

overlay the associated runway, with the width or sides of the zone extending a constant 

distance from both sides of the runway, and length or ends of the zone extending a constant 

distance from both thresholds of the runway. The zone extends vertically a constant 

altitude above the runway surface. The 3-dimensional incursion zone is the only place 

where flight operations are monitored for runway incursions/conflicts. Figure 1 shows a 

two-dimensional plan view of the runway incursion zones at the Reno airport. Figure 2 

shows the runway incursion zones at Wallops. 

Accurate placement of the incursion zones is critical for correct performance of the 

algorithm and prevention of false alarms. The coordinates for each runway incursion zone 

are computed based on information in the RSM configuration file (see Section 3.1.4) for 

individual runway parameters such as thresholds and widths. The values for the sides and 

ends of the zones can vary for each runway. The sides of a zone are set to be near the hold 

short positions but not too close to set off false alarms if aircraft are stopped with the nose 

over the hold line. The ends of zones vary based on the intersection of the ILS glide slope 

path with the incursion zone altitude. If there is no ILS, a standard glide slope for the 

runway is used. Zones typically extend approximately 2.2 nm from the runway threshold. 

The width of incursion zones is wider at the approach ends than at the runway thresholds 

(see Figures 1 and 2). This difference is due to the allowance of up to a two-dot ILS 

localizer deviation error on approaches. 

When the ownship is using a runway, intentionally or by mistake, the positions of other 

traffic inside the incursion zone for that runway are continually tracked. (See definition of 

other traffic in Section 2.1 above.) In addition, the positions of other traffic inside 

incursion zones that cross the ownship’s incursion zone are also tracked. Only the runway 

zone used by the ownship and any zones that cross the ownship’s zone are monitored for 

other traffic. Conflicts between other traffic that do not involve the ownship are not 

detected. Note that when the ownship is not using a runway, traffic is not monitored in any 

runway incursion zone. Also, any possible conflict between the ownship and other traffic 

outside or above the runway zones (such as on taxiways, non-approach areas, etc.) is not 

considered a runway conflict and, therefore, is not monitored by RSM. 
6

2.3 Incursion Scenarios 

RSM was designed to detect all possible scenarios for runway incursions/conflicts, 

including conflicts on single runways, crossing runways and intersecting flight paths. This 

is a significant upgrade from the previous DFW flight test where only single runway 

conflicts were detected. Common conflict scenarios on single runways include: ownship 

entering the runway while another aircraft is taking off or landing; ownship landing or 

taking off while another aircraft/vehicle is taxiing across the runway or construction 

equipment is located on the runway; and one aircraft landing while another aircraft is on 

takeoff roll (chase scenario), holding in position for take off, or not yet off the runway from 

a previous landing. Aircraft or vehicles can wander onto a runway by mistake while the 

runway is in use. Another single runway scenario added to RSM is when the ownship is 

taxiing toward a runway with departing or arriving traffic but is either unable to stop or 

does not intend to stop before reaching the hold short line. In this case, RSM may alert 

before reaching the hold line based on a look-ahead or projection capability. 

Typical conflict scenarios on crossing runways are as follows: ownship begins takeoff 

while another aircraft is taking off on a crossing runway (departure/departure) or landing 

on a crossing runway (departure/arrival); and ownship is landing while another aircraft is 

taking off on a crossing runway (arrival/departure) or landing on a crossing runway 

(arrival/arrival). Intersecting flight paths are similar to crossing runways but result in 

different situations that require different incursion detection criteria depending on where 

the flight paths intersect. For example, the intersection can be located before the threshold 

of the arrival runway or beyond the end of the departure runway. There are many different 

scenarios and variations of each scenario if all the possible combinations of conditions are 

considered. 

By definition, an incursion or conflict scenario usually involves the ownship and another 

aircraft, with one or both in the process of taking off or landing, or intending to take off or 

land (see Section 1.0). However, operations when neither aircraft is taking off or landing 

(taxi only operations) can generate possible conflicts if one of the taxiing aircraft is on the 

runway after a rollout, before a takeoff roll or when the runway is used as a taxiway. These 

taxi only scenarios have been added to the RSM’s detection and alerting capabilities using 

strict criteria to prevent false or nuisance alerts. 

 

During GVSITE, four different scenarios were tested at RNO and seven scenarios were 

tested at WAL, with highly successful results. Fewer scenarios were tested at RNO due to 

airport restrictions. The flight test included some common crossing runway scenarios 

described above as well as some single runway scenarios that were not previously tested 

during the DFW flight test. All scenarios involved a Gulfstream-V (GV) aircraft fully 

equipped with a NASA research system and used as the ownship. A Be200 King Air 

general aviation aircraft and a NASA test van were equipped with ADS-B (Automatic 

Dependent Surveillance – Broadcast) transponders and used as other traffic during the 

RIPS scenarios. The scenarios tested at WAL are shown in Figures 3 – 9 and the scenarios 

tested at RNO are shown in Figures 10 – 13. A detailed description and RSM performance 

results for each scenario are described in Section 4.0. 
7

3.0 THE RSM ALGORITHM – TECHNICAL APPROACH 

RSM is a standalone software program that receives airport traffic and ownship data as 

input, calculates if the conditions exist for a potential runway conflict, and issues alerts, if 

necessary, for display to the pilot. The algorithm is programmed in the C language and is 

integrated with the RIPS communications and display software through shared memory 

inter-process communications. Although RSM runs as a separate program, it interfaces 

with the RIPS communications software for access to ownship and traffic data, and 

provides alert data to the RIPS display software for aural and graphical display to the pilot. 

The technical approach is described here in sufficient detail to provide an understanding of 

how the algorithm works without going into the low level programming details. A high 

level flow diagram for the algorithm is provided in Figure 14. 

3.1 General Description 

3.1.1 Operational States and Operational State Matrices 

The capability to detect any type of runway conflict is accomplished using a generic 

approach that is based on the concept of operational states and operational state matrices. 

Because there are so many possible conflict scenarios, a generic approach is more effective 

than attempting to identify all the possibilities and program for each case separately (see 

Section 2.3). Seven operational states or flight phases are defined and applicable for both 

ownship and traffic: 

taxi state: aircraft/vehicles taxiing or not moving and stationary objects/equipment. 

pre-takeoff state: ownship positioned for takeoff but before or at the beginning of a 

 takeoff roll. (This state is not available for traffic.) 

takeoff roll state: ground takeoff roll in progress, not airborne. 

climbout state: airborne climb out after takeoff roll or after aborted landing. 

landing state: airborne and on final approach. 

rollout state: ground roll out after landing or after an aborted takeoff. 

fly-thru state: flying through/crossing the incursion zone but not landing or taking off. 

The states form a matrix of seven ownship states and six traffic states for a total of 42 

possible state combinations for ownship and traffic. The pre-takeoff state is not available 

for traffic due to lack of data. Each combination of ownship state and traffic state in the 

matrix determines whether or not a conflict is possible for current conditions. If the matrix 

indicates a conflict is possible, additional alerting criteria are applied to determine if a 

conflict alert should be issued. There are actually two operational state matrices used by 

the algorithm, one for single runway conflicts and one for conflicts on crossing runways or 

intersecting flight paths (see Figures 15 and 16). The two state matrices are separate 

because the alerting criteria are very different for single and crossing runways. The 

operational state matrix methodology has proven to be highly effective in both the RIPS 

DFW flight test and the GVSITE flight test. A detailed description of this methodology is 

provided in Sections 3.2.3 and 3.2.4. 
8

3.1.2 Software Design 

The overall software design for RSM is straightforward; however, the implementation is 

fairly complex with the addition of crossing runways, intersecting flight paths and other 

capabilities. The algorithm design consists of five components summarized briefly below. 

A detailed breakdown of the design is provided in Section 3.2. 

Component 1, RSM Main, is the main loop that interfaces with the RIPS shared memory to 

obtain the latest ownship and traffic data, and then calls the algorithm (components 2 – 5) 

to perform runway conflict analysis and testing. When conflict testing is completed, RSM 

Main’s output function writes the conflict alert data to the RIPS shared memory. 

Component 2, Setup and Testing Status, determines the ownship operational state and 

whether or not runway conflict testing should be started, continued or terminated. If 

conflict testing is not started or continued, the RSM alert data is cleared and the algorithm 

returns to RSM Main without further action; otherwise, testing is initiated by calling 

Component 3. 

Component 3, Conflicts in the Ownship Zone, tests for conflicts in the runway zone being 

used or crossed by ownship. This component finds and tracks all traffic inside the 

ownship zone, and tests for conflicts using the operational state matrix and alerting criteria 

for single runway conflicts. 

Component 4, Conflicts in Crossing Zones, tests for conflicts in other runway incursion 

zones that intersect with the ownship zone. This function is a new capability for RSM that 

was not available at DFW. The software cycles through each zone that crosses the ownship 

zone, finds the traffic and tests for conflicts using the operational state matrix and alerting 

criteria for crossing runways and intersecting flight paths. 

Component 5, Processing Conflict Data, processes the conflict alert data generated by 

components 3 and 4. The processed data are written to a local RSM alert data structure for 

access by the alert data output function in RSM Main (Component 1). If there are no 

conflicts, the alert data structure is cleared. 

3.1.3 Interfacing With RIPS Software 

The five components listed above describe, in general, how RSM performs the critical 

function of runway conflict detection and alerting for NASA RIPS. However, RSM 

utilizes the services of other RIPS software components to propagate the alert data, process 

and format the data, and finally issue the alert information to the pilot aurally and/or 

graphically. The RIPS software contains an important function that checks for alert data 

produced by RSM or any other algorithm, initiates or terminates conflict alert displays and 

aural warnings, and makes the conflict alert messages available for down linking to the 

ground controller. Although not part of RSM per se, the graphics display symbologies and 

aural warnings generated by the RIPS software are an important area of ongoing research in 

human factors to determine the best methodologies for conflict alerting and enhanced 

situational awareness to the flight crew. Example displays that were used during the 
9

GVSITE flight test at RNO and WAL are shown in Figure 17a – 17c. These displays show 

alerts for single runway conflicts with ownship landing on approach and traffic taxiing 

across the arrival runway. 

3.1.4 Criteria and Parameters 

Detection of runway conflicts is based on criteria for placement of the runway incursion 

zones, criteria for determining ownship and traffic operational states and alerting criteria 

for single runways and crossing runways/zones. Many of these criteria depend on variables 

that are derived or computed from various sources including the ownship flight 

management system data and traffic data. However, some criteria are based on predetermined constant values and configuration parameters. The program constants are hard 

coded and not changeable. The configuration parameters, contained in RSM configuration 

files read during RSM startup or re-initializations, can be modified. Since parameters can 

vary depending on the airport conditions, ATC requirements and type of aircraft, the use of 

configuration files allow the values to be readily changed without recompiling the software. 

For example, RSM can be configured for different types of ownship aircraft by simply 

changing the ownship configuration file and the conflict alerting parameters can be 

modified based on whether ownship is a large commercial jet, a general aviation aircraft or 

other factors. Many new, configurable parameters have been added to RSM since the DFW 

flight test to refine the algorithm performance and adaptability. 

3.2 Logic and Data Flow 

The logical operations and data flow of the RSM algorithm are described in the following 

sub sections. Refer to Figure 14, RSM Algorithm – High Level Flow Diagram. Note that 

in the descriptions below, traffic will often be referred to as targets. Target is a more 

general term that includes aircraft, vehicles, construction objects, runway equipment, etc. 

3.2.1 Component 1: RSM Main 

RSM main is a continuous timed loop whose primary task is to call functions to get current 

traffic and ownship data from the RIPS shared memory interface, call the algorithm to 

perform conflict detection analysis, and write the conflict alert data received from the 

algorithm back to the RIPS shared memory interface. Other functions handled by RSM 

main include startup, shutdown and re-initialization when the airport is changed. Optimal 

timing of the RSM main loop was found to be once per second based on the minimum data 

rate for traffic. More frequent iterations were less effective because many traffic data 

elements were often not updated once per second necessitating data estimation and/or 

interpolation (see Section 3.2.3.1.1). 

3.2.1.1 Traffic Data Function 

RSM main calls the traffic data function to determine the availability of new traffic data in 

RIPS shared memory and make a local copy for access by the algorithm. During this 
10

process, some data elements are converted to different units based on the algorithm 

requirements. Two primary traffic data sources were used during the GVSITE flight test, 

ADS-B (Automatic Dependent Surveillance – Broadcast), and a traffic data fusion system, 

called Multi-Tracking System (MTS), on the Gulfstream-V aircraft. The ADS-B 

transmissions from the BE200 and van were data linked to the Gulfstream. The MTS on 

board the aircraft provided a single fused source from ADS-B, TCAS (Traffic Collision 

Avoidance System), and aircraft radar sources. The fused data and the raw data for ADSB, TCAS and radar were stored in separate areas in the RIPS shared memory. The data 

source, ADS-B or fused, was selected prior to each flight test run. 

3.2.1.2 Ownship Data Function 

 

When the traffic function completes the acquisition of new data, RSM main calls the 

ownship function to read the latest aircraft flight management system (FMS) data from 

RIPS shared memory. This data is also copied to a local data structure tailored for use by 

the algorithm and converted to different units, as required. 

3.2.1.3 Alert Data Output Function 

 

Upon completion of conflict testing by the algorithm, RSM main copies the conflict alert 

data directly to the RIPS shared memory interface. If there are no conflicts, the data are all 

zeros. After this final step, the whole process reiterates and checking for traffic/ownship 

data updates begins anew. 

3.2.2 Component 2: Setup and Testing Status - Start/Stop/Continue Conflict 

Testing 

If traffic data is available from RSM main, the algorithm has to decide whether to test for 

conflicts or do nothing and return. If not currently testing, Component 2 determines if 

testing should be started and, if so, what runway incursion zone is in use. If testing is 

already being performed, the algorithm determines if incursion testing should be continued 

or terminated. The testing status is determined based on the ownship operational state 

described in Section 3.1.1 and the conditions described below. If incursion testing is not 

required or is terminated based on either the ownship state or non availability of traffic 

data, any data previously saved is cleared and the algorithm returns to RSM main without 

further action. It is important to point out that the algorithm starts from scratch each time it 

is called, at least once per second, and assumes there are no conflicts even if a conflict alert 

is currently in progress. For each call, the current data is reanalyzed, testing status and 

operational states are re-determined, and all traffic is retested for conflicts. Any alert in 

progress will be continued or discontinued, or a new alert will be initiated based on the 

most current data and analysis. 

Incursion testing on the ground. If ownship is on the ground, incursion testing is 

initiated if the aircraft is found to be inside of any runway incursion zone and is 

terminated if ownship exits the zone. The zone may be exited if ownship taxies off 

the runway, takes off and flies outside the zone perimeter or climbs above the 

incursion zone altitude. 
11

Incursion testing in the air. If ownship is airborne, incursion testing is started if the 

aircraft is on final and enters the approach end of the runway incursion zone. The 

distance of the approach end of the incursion zone from the runway threshold is 

computed based on the intersection of the ILS glide slope angle, or a default glide 

slope angle in the configuration file, if no ILS, and the incursion zone altitude. For 

GVSITE, this distance varied for each runway but was approximately 13264 feet 

(2.2 nm) from the ends of the runways based on a glide slope angle of 3 degrees and 

an incursion zone altitude of 800 feet. Note: The zone altitude of 400 feet used for 

the DFW flight test resulted in a zone approach end distance of 1.1 nm. The higher 

values used for GVSITE were optimal for detection of crossing runway conflicts 

and for early detection of traffic landing on approach. If incursion testing is started 

in the air, it is terminated when ownship lands and exits the incursion zone, flies 

outside the zone, or aborts the landing by turning and/or climbing above the zone. 

3.2.3 Component 3: Single Runway Conflicts 

If incursion testing is required, this component starts the testing process for conflicts inside 

the runway incursion zone used by the ownship (called the ownship zone). Testing for 

conflicts in the ownship zone uses single runway conflict criteria similar to the criteria 

tested at DFW in 2000. Since then, the single runway criteria have been enhanced to 

improve performance and capabilities. Component 3 performs two main tasks: traffic 

monitoring to find and save data for traffic inside the ownship zone (Section 3.2.3.1) and 

conflict detection in the ownship zone (Section 3.2.3.2). 

3.2.3.1 Monitoring Traffic in the Ownship Zone 

This function checks each target in the traffic data list structure populated by RSM main. If 

a target is inside the ownship zone, the data for that target is saved in a separate list for 

ownship zone targets. A maximum of five targets can be saved in the ownship zone list. 

There should rarely be more than five targets in a single runway zone at the same time, but 

this parameter can be changed in the RSM configuration file, if necessary. If a target is no 

longer available or no longer in the ownship incursion zone, its data is cleared from the 

zone list, freeing space for any new targets found in the zone. Zone targets are tracked by a 

unique non-zero numeric ID number or an alpha-numeric flight number if available. If 

neither numeric ID nor flight number is available, the target is labeled as an unknown target 

in the zone. It could be a false target caused by erroneous data, or a valid target that has 

missing IDs. The algorithm tracks only one unknown target because there is no accurate 

way to uniquely identify and store the target data. If there is more than one unknown target 

in the zone, all unknown targets are discarded. 

3.2.3.1.1 Computing and Smoothing Traffic Data 

 

The data reported for each target includes the Global Positioning System (GPS) latitude 

and longitude position, altitude in feet above mean sea level (MSL), ground speed in knots, 

track angle in degrees true and a time stamp for the data. Other data needed by the 
12

algorithm such as acceleration, vertical speed, closing distance, etc., must be computed 

from the reported values. The reported values are updated at regular intervals depending 

on the source of the data. Ideally, the data rate will be at least once per second. However, 

as discovered during both the DFW and GVSITE flight tests, the one second traffic updates 

are the exception rather than the rule. 

When all or any specific reported values are not up to date, an estimate of the current 

value(s) must be made by projecting the last known values. This process, known as data 

smoothing, involves computations that decrease in accuracy with increasing time between 

updates, and is further complicated by different data rates for specific values and 

uncertainty in the exact time since the last update. For example, the position update might 

be at one hertz but the update rate for ground speed is two or three hertz and the exact 

update times may not be known. Because the accuracy of traffic data is so critical to 

correct conflict detection, a great deal of effort has been made to insure that traffic 

smoothing and computations of non-reported values are as accurate as possible. 

3.2.3.1.2 Determining the Traffic Operational State 

The traffic state for each target is determined after all the data values for that target have 

been derived, computed and/or smoothed. The correct performance of RSM depends on 

how accurately this process is performed. (See definition of operational states in Section 

3.1.1.) The criteria used to determine traffic state have been derived empirically based on 

numerous flight simulations and flight testing. The criteria for ground based traffic 

include: ground speed above or below a defined maximum taxi speed; acceleration above 

or below a takeoff acceleration threshold; on or off the runway and heading in the general 

direction of the runway. The criteria for airborne traffic include: altitude above or below 

the incursion zone altitude; vertical speed and track lined up with the runway (within angle 

tolerance). If a target’s altitude is above the zone altitude, no further testing is done for the 

target; however, its data is maintained in the zone target list and monitored on subsequent 

traffic scans in the event the target drops below the zone altitude. In some cases, the 

threshold values for the state criteria are defined as parameters in RSM configuration files 

so they can be modified for different airport/aircraft requirements. 

3.2.3.2 Detecting Conflicts in the Ownship Zone 

When the traffic monitoring function finds a target in the ownship zone, obtains accurate 

data for the target and determines the traffic state, testing of this target for conflicts is 

performed using the operational state matrix and alert criteria for single runways (Figure 

15). It is possible to have more than one conflict occurring at the same time in ownship’s 

incursion zone. Currently, there is a limit of two simultaneous conflicts. This limit has 

been adequate in testing, but if necessary, the limit can be increased by allocating more 

memory space for alert data. 

3.2.3.2.1 Applying Operational State Matrix & Alert Criteria for Single Runways 

A conflict is considered possible based on the combination of operational states for 

ownship and the target (see Figure 15). If a state combination results in the possibility of a 

conflict, i.e., a YES in the matrix, additional alerting criteria are tested to determine if a 
13

conflict situation is in progress. The specific alerting criteria vary based on state 

combination. For example, if ownship is on a takeoff roll and a target is taxiing, the 

alerting criteria include horizontal distance closure between ownship and target. But if 

both ownship and target are in the process of taking off or landing, the alerting criteria 

include directions of movement, separation distance, and distance closure. In these cases, 

when ownship and target directions of movement are the same, it is a chase situation and is 

a conflict if distance is less than a defined minimum separation, i.e., loss of separation. 

When directions of movement are opposite, it is a head-on conflict and minimum 

separation is not applicable. The following is a more detailed description of the more 

common types of conflicts identified by the operational states matrix. 

Both ownship and target in the taxi state: 

A taxi only operation occurs when both ownship and the target are taxiing or stationary. 

This situation was not considered for incursion testing at the time of the DFW flight 

test. However, new capabilities in the current version of RSM monitor the taxi only 

operations for potential conflicts if at least one aircraft is taxiing after a landing rollout 

or aborted takeoff, or if two aircraft get too close on the runway. 

Ownship in the pre-takeoff state: 

When ownship is on the runway in position for takeoff or just starting takeoff roll, the 

ownship state is changed from taxi to pre-takeoff state. The pre-takeoff state indicates 

the “intent” to takeoff immediately. The criteria used to determine this state include 

being on the runway with the same heading as the runway and acceleration, but may 

also include takeoff mode and throttle position depending on the type of aircraft and the 

availability of flight data. 

The pre-takeoff state can only be determined for ownship at the present time since the 

intent of other traffic cannot be known a priori. For this reason, the operational states 

matrix does not include a pre-takeoff column for targets. Traffic must be well into the 

takeoff roll as indicated by speed, acceleration, etc., before intent to takeoff is known. 

Significant improvements have been made in the advanced version of the algorithm to 

detect traffic takeoffs as soon as possible at the beginning of the takeoff roll. However, 

further improvements can only be made if additional traffic “intent” data become 

available. 

When ownship is in the pre-takeoff state, a conflict is possible for any target state. 

However, additional alerting criteria must be tested to prevent false alarms. If the target 

is taxiing or stationary, the target must be ahead of ownship in the takeoff path and not 

clear of the runway. If the test for these criteria returns true, a conflict alert (RCA) will 

be generated either before ownship starts the takeoff roll or very early in the takeoff 

roll. For example, if the target happens to be stationary equipment on the runway and 

ownship is in the pre-takeoff state, the hazard would be recognized immediately and the 

alert would be issued prior to any movement that could cause a collision. 
14

Either ownship or target in a landing/takeoff state while the other is in a taxi state: 

The state conditions in this category include combinations of ownship landing/taking 

off and target taxiing/stationary or target landing/taking off and ownship 

taxiing/stationary. The landing and takeoff states include takeoff roll, climb out, 

landing approach and roll out. For any of these conditions, the primary alerting criteria 

are taxiing/stationary traffic not clear of the runway and decreasing separation between 

ownship and the target (closure). Other criteria are also applied to prevent false alarms 

depending on the combination of states. 

The criterion for separation closure is necessary to prevent false alarms by 

distinguishing non-conflicting targets located behind an aircraft on takeoff or landing. 

A positive closure rate indicates that the taxiing aircraft or vehicle is in the direct path 

of the aircraft taking off or landing. For example, if ownship is taxiing across the hold 

short line and enters the incursion zone while a target aircraft is on takeoff roll or 

landing, a conflict will be detected immediately and an alert will be generated in 

sufficient time to stop the aircraft before reaching the runway. Or, if ownship is on a 

takeoff roll and a target is crossing the runway in the takeoff path, an alert will be 

issued before ownship’s ground speed becomes too high for a rejected takeoff. If 

ownship is on final approach, an alert will be issued with sufficient lead time, distance 

and altitude to abort the landing and go around. 

A new capability was developed after the DFW flight test for situations when ownship 

is taxiing toward a runway but is taxiing too fast to stop before the hold line or may not 

intend to stop. The algorithm computes a projected position ahead of the aircraft (a 

look-ahead point) based on the taxi speed, deceleration, stopping distance and other 

factors. If the look-ahead point enters the incursion zone of an active runway with 

traffic taking off or landing, an alert will be generated that will allow ownship to stop 

before the hold line. If ownship is already slowing down before reaching the hold line, 

the look-ahead point recedes closer to the nose of the aircraft and an alert will not be 

generated. 

Both ownship and target in the landing or takeoff state: 

The state conditions in this category include all combinations of both ownship and 

target taking off and/or landing. These situations are potential conflicts since no more 

than one landing or takeoff operation should occur at any one time on the same runway. 

A chase situation occurs when both aircraft are landing or taking off in the same 

direction, or one is landing from behind while the other is taking off. In these cases, the 

alerting criterion for minimum separation distance is used to detect loss of separation. 

If two land or takeoff operations are in opposite directions, an alert is issued regardless 

of separation distance. 

Fly-thru states: 

One other aircraft operational state is possible for ownship and traffic that is neither taxi 

nor land/takeoff. The fly-thru state occurs when the aircraft is airborne and is flying 

across the runway incursion zone below the incursion zone altitude. Note that an 
15

aircraft flying in the incursion zone with the same heading as the runway would be 

interpreted as a landing or takeoff, not a fly-thru state. The fly-thru state may occur 

when rotary aircraft/helicopters fly within the airport boundary at low altitudes directly 

across runways. More often, the fly-thru state is observed when aircraft on final 

approach to a runway cross an intersecting incursion zone for another runway. Fly-thru 

states can generate incursions; however, to avoid issuing alerts that are false alarms, 

additional alerting criteria must be tested. For example, if ownship is taking off or 

landing and a target is observed inside the zone in the fly-thru state, an alert will be 

issued if alerting criteria indicate that the target is in ownship’s takeoff or landing path 

and the distance is less than the minimum separation. In this example, a helicopter 

could be crossing the runway at a low altitude immediately in front of the departing 

aircraft. Another example is when ownship is taking off and another aircraft on 

approach to a different runway crosses ownship’s runway zone near the end where the 

two zones intersect. In this case, an alert may not be issued if the distance between 

aircraft is greater than the minimum separation. 

3.2.3.2.2 Aging Conflict Alerts 

When a conflict alert is generated, it is possible that the conflict will appear to no longer 

exist when subsequent traffic data is received. This can happen when the traffic data are 

erratic and inconsistent, i.e., bad data is received followed by good data. In this case, an 

aural and visual alert might be issued, then terminated, then reissued several times for the 

same conflict and can be very distracting to the pilot and crew. One technique used by 

RSM to minimize this on-off alert sequence is to age or coast the conflict alert for one or 

two seconds after the conflict ends. Aging the alert has the effect that multiple alerts are 

less likely to be issued for the same conflict and only one alert will be issued unless there 

are continued problems with the data. Alert aging can also occur even when the data is 

good under some conditions, but does not apply if an alert is terminated because either 

ownship or the target involved in the conflict is no longer inside the incursion zone or is 

above the incursion zone altitude. 

3.2.4 Component 4: Crossing Runway and Intersecting Flight Path Conflicts 

After testing for conflicts in the ownship zone, Component 4 starts the process of testing 

for conflicts in other runway incursion zones that intersect the ownship zone. The 

intersection point can be on the runway itself, i.e., a crossing runway, or at points before or 

beyond the ends of the runway, i.e., crossing flight path. Either of these situations is 

referred to in RSM as a crossing runway incursion zone or just crossing zone. The 

capability to detect conflicts in crossing zones is a major enhancement to RSM that was not 

available for the DFW flight test but has been tested extensively in the flight simulator and 

during the GVSITE flight test. The software design methodology for crossing zones is 

similar to the methodology for single runways. A major difference is that there may be 

more than one crossing zone that has to be monitored for traffic and tested for conflicts. 

Also, the operational state matrix and alerting criteria for crossing zones are significantly 

different than the matrix and criteria for single runways. Just as for single runways, the two 

main tasks are traffic monitoring to find and obtain data for traffic inside each crossing 
16

zone and conflict testing in each crossing zone. Traffic monitoring for crossing zones is 

done the same way as traffic monitoring in the ownship zone described in Section 3.2.3.1 

above. The following is a description of how conflicts are detected in crossing zones. 

3.2.4.1 Detecting Conflicts in the Crossing Zones 

When the traffic monitoring function finds a target in a crossing zone, obtains accurate data 

for the target and determines the traffic state, testing of this target for conflicts is performed 

using the operational state matrix and alerting criteria for crossing zones (Figure 16). As 

for single runway conflicts, there is a limit of two simultaneous conflicts in a crossing zone 

but this would be a very rare occurrence. In the unlikely event there is a total of more than 

two conflicts in the ownship zone and all crossing zones, conflicts are prioritized with 

ownship zone given highest priority followed by crossing zones closest to the ownship 

position. The aging of conflict alerts (Section 3.2.3.2.2) is also applicable for crossing zone 

conflicts. 

3.2.4.1.1 Applying Operational State Matrix & Alert Criteria for Crossing Zones 

A conflict is considered possible based on the combination of operational states for 

ownship and the target (Figure 16). If a state combination results in the possibility of a 

conflict, i.e., a YES in the matrix, additional alert criteria are tested to determine if a 

conflict situation is in progress. The alert criteria differ based on the combination of states 

in the matrix. For example, the alert criteria are different for the combinations of ownship 

takeoff roll / traffic takeoff roll and ownship land / traffic land. It also makes a difference 

where the common intersection is located, i.e., whether the runways directly cross each 

other or one runway crosses the flight path of another runway or both runway flight paths 

cross each other. The following is an explanation of the common scenarios identified by 

the operational state matrix for crossing zones. 

No conflict scenarios: 

If the target is in a taxi/stationary or fly-thru state, no conflict alert is issued. A conflict 

is considered possible only if traffic is taking off or landing and will cross the common 

intersection with ownship’s runway. If traffic is in a taxi or fly-thru state on a crossing 

runway and enters ownship’s runway incursion zone, this situation will be tested for 

single runway conflicts described in Section 3.2.3 above. 

Ownship taxi/fly-thru two zones: 

This situation occurs when ownship is taxiing on a runway, e.g., after a rollout or when 

the runway is used as a taxiway, and enters the crossing zone of another runway where 

traffic is landing or taking off. In this case, ownship is in two runway zones at the same 
17

time. This scenario does not use alert criteria for crossing zones but uses single runway 

criteria for both zones that ownship is in. The situation also covers rare cases when 

ownship could be flying through the common intersection of two runways. This case is 

also handled as two separate single runway scenarios. 

Departure/departure scenarios: 

These scenarios involve all combinations of ownship departure states (pre-takeoff, 

takeoff roll or climb-out), and traffic departure states (takeoff roll, climb-out) when 

traffic is in a crossing zone such as crossing runway or intersecting flight path. For 

these scenarios, alerting criteria are based on ATC guidelines for intersecting runway 

separation when both the ownship aircraft and another aircraft are departing [Ref. 6, 

Para 3-9-8]. These guidelines specify that the departing aircraft does not begin takeoff 

roll until the other departing aircraft has passed the intersection or is turning to avert 

any conflict. To satisfy these guidelines, RSM issues a conflict alert as early as 

possible during ownship’s departure so the takeoff can be easily aborted to avert any 

possibility of a collision. The ideal is to alert during ownship’s pre-takeoff state when 

ownship is not moving or has just started the takeoff roll. This is only possible if traffic 

on the crossing runway has already its started takeoff roll or is climbing out and is not 

past the intersection. If ownship starts its takeoff roll first, the alert will occur later 

after traffic begins takeoff. If ownship starts takeoff first and the other departing 

aircraft is also equipped with RSM, that aircraft would get a conflict alert that would 

result in a rejected takeoff. 

Departure/arrival scenarios: 

These scenarios involve all combinations of ownship departure states (pre-takeoff, 

takeoff roll, climb-out) and traffic arrival states (land, rollout) when traffic is in a 

crossing zone. Alerting criteria are based on ATC guidelines for intersecting runway 

separation when the ownship aircraft is departing and another aircraft is arriving [Ref. 

6, Para 3-9-8]. These guidelines specify that the departing aircraft shall not begin its 

takeoff roll until the arriving aircraft is clear of the landing runway, has completed the 

landing roll and will hold short of the intersection, or has passed the intersection. Just 

as for departure/departure scenarios above, alerts for departure/arrival scenarios are 

issued as early as possible during ownship’s departure. 

Arrival/departure scenarios: 

These scenarios involve all combinations of ownship arrival states (land, rollout) and 

traffic departure states (takeoff roll, climb-out) when traffic is in a crossing zone. 

Alerting criteria are based on ATC guidelines for intersecting runway separation when 

the ownship aircraft is arriving and another aircraft is departing [Ref. 6, Para 3-10-4]. 

These guidelines specify that the arriving aircraft shall not cross the landing threshold 

or flight path of the departing aircraft until the departing aircraft has passed the 

intersection/flight path or is airborne and turning to avert any conflict. To satisfy these 

guidelines, RSM issues a conflict alert when ownship is far enough from the landing 

threshold or flight path intersection to take evasive action to avert a conflict (e.g., goaround). 
18

Arrival/arrival scenarios: 

These scenarios involve all combinations of ownship arrival states (land, rollout) and 

traffic arrival states (land, rollout) when traffic is in a crossing zone. Alerting criteria 

are based on ATC guidelines for intersecting runway separation when the ownship 

aircraft is arriving and another aircraft is arriving [Ref. 6, Para 3-10-4]. These 

guidelines specify that the arriving aircraft shall not cross the landing threshold or flight 

path of the other aircraft (intersection) until the arriving aircraft is clear of the landing 

runway, has completed landing roll out and is holding short of the intersection, or has 

passed the intersection/flight path. Just as for the arrival/departure scenarios, alerts for 

arrival/arrival scenarios are issued when ownship is a sufficient distance from the 

landing threshold or flight path intersection to take evasive action to avert a conflict. 

3.2.4.1.2 Land And Hold Short Operations 

Land and hold short operations (LAHSO) are in use at many airports to control traffic on 

crossing runways. These operations are germane to conflict detection and alerting because 

the ATC guidelines do not consider a situation to be a conflict if an arriving aircraft has 

completed the landing roll out and will hold short of the intersection. LAHSO operations 

present some problems for RSM due to lack of information when these operations are in 

effect. The LAHSO instructions from the ATC controller apply to ownship’s runway, 

traffic on a crossing runway or both. If ownship is instructed to land and hold short of an 

intersection, it is not a conflict when traffic is taking off or landing on the crossing runway. 

Conversely, if traffic is instructed to land and hold short, ownship can land or takeoff 

without a conflict. However, RSM has no way of knowing when and what LAHSO 

instructions have been issued and, therefore, cannot integrate these operations. Even if the 

operations are known, other factors must be considered such as when landing roll out is 

completed and the aircraft’s ability to stop or turn off before the intersection. 

The current version of RSM considers these and other factors in the conflict alerting 

criteria. For example, an alert will not be issued if the aircraft has completed its rollout 

before reaching a certain distance from the intersection and will be able to stop with a 

normal deceleration for the type of aircraft. RSM currently assumes that no LAHSO 

instructions are in effect for either runway. However, future capabilities with Controller 

Pilot Data Link Communications (CPDLC), and/or enhancements to traffic data may 

provide the necessary information to consider LAHSO. 

3.2.5 Component 5: Processing Conflict Alert Data 

After conflict testing is completed for all applicable runway incursion zones (Components 

3 and 4), Component 5 processes and formats the alert data for output to RIPS software 

through RSM Main. This function involves writing the alert data to a local RSM alert data 

structure that includes a numeric value for the type of alert (RCA – see Section 2.1), a 

numeric id for other traffic involved in the conflict, the distance to the conflict in feet and 

the time in seconds to the conflict. Distance and time to the conflict are based on the 

separation from ownship to the target for single runway conflicts and the separation from 
19

ownship to the intersection for crossing zone conflicts. The alert variables are based on the 

information needed for alert displays in the cockpit, but can be changed to meet future 

display requirements. If there are no conflicts, the alert data structure is cleared. Alert data 

can be written for one conflict or for two simultaneous conflicts in the same or different 

incursion zones. In the unlikely event there are more than two conflicts, any conflict in the 

ownship zone has highest priority followed by conflicts in crossing zones closest to the 

ownship position. When alert processing is completed, control is returned to RSM main 

where the alert data output function is called (see Section 3.2.1.3). Note that the alert 

processing function in Component 5 no longer writes alert data directly to RIPS shared 

memory as it did during the DFW flight test. This output function has been encapsulated in 

RSM main so the method of inter-process communications, currently a shared memory 

interface, can be changed without affecting any of the algorithm code. 

4.0 RSM PERFORMANCE RESULTS 

The RSM algorithm was tested extensively during the GVSITE flight tests at Reno and 

Wallops in July and August 2004. Data from all flight tests were recorded by RIPS 

communications software on board the GV for playback and post analyses. Data were also 

recorded by the Synthetic Vision System (SVS) software and made available for use in the 

event RIPS recordings were missing or corrupted. The performance results are 

summarized for each of the runway incursion scenarios that were tested at Reno and 

Wallops. Seven scenarios were tested at Wallops (Figures 3 – 9) and four scenarios were 

tested at Reno (Figures 10 – 13). These scenarios were chosen to evaluate new capabilities 

of RSM, including alerts for crossing runway conflicts, alerts during taxi operations to 

prevent crossing the hold line when a runway is active, and alerts for conflicts with arriving 

traffic when ownship is holding for takeoff. Tables 1 and 2 list the overall performance 

results for Wallops and Reno, respectively. All scenarios used the GV research aircraft as 

the ownship, a BE200 King Air general aviation aircraft as other traffic, and a NASA 

research test van as vehicle traffic. The test results for each scenario will be followed by an 

overall performance summary with lessons learned during GVSITE. 

4.1 Incursion Scenario 1 – Crossing Runway 

 Ownship Departure / Traffic Departure 

During Scenario 1, the GV (ownship) was taking off while the BE200 (traffic) was 

simulating a takeoff on a crossing runway. The BE200 was required to accelerate to a 

speed of 40 to 50 knots, hold that speed as long as possible then slow down and stop before 

the intersection. The GV evaluation pilot was trained to execute a rejected takeoff (RTO) 

upon receipt of the Runway Conflict Alert (RCA). The timing conditions varied for each 

Scenario 1 test run. Sometimes the BE200 was released to start the simulated takeoff 

before the GV began its takeoff roll and at other times the GV started takeoff first. A 

runway conflict was considered to be in progress when both aircraft were in the process of 

taking off. 
20

 Results for Wallops (Figure 3, Table 1): There were a total of 8 data runs for Scenario 

1 at Wallops. RSM issued RCA’s on all 8 runs. There were no late or false alerts. The 

starting takeoff position for the BE200 on the crossing runway averaged 1275 ft from 

the threshold because the beginning section of the runway was closed. When the RCA 

was issued, the average ground speed for the GV was 65 knots and the average ground 

speed for the BE200 was 18 knots. These numbers indicate that normally the GV was 

already into the takeoff roll when the BE200 started its takeoff and the takeoff state for 

the BE200 was detected very early (with speed below 20 knots and an average of 135 ft 

from start position). The RTO was executed after the RCA when the GV was an 

average of 78 knots and 4626 ft from the intersection. The conflict alert resulted in the 

RTO being executed with more than sufficient lead time and distance from the 

intersection to stop safely and avert the possibility of a collision. 

 Results for Reno (Figure 10, Table 2): There were a total of 11 data runs for Scenario 1 

at Reno. RSM issued RCA’s on all 11 runs and there were no late or false alerts. 

When the RCA was issued, the average ground speed for the GV was 49 knots, and the 

ground speed for the BE200 averaged 33 knots and 536 ft from the starting takeoff 

position. The RTO was executed after the RCA when the GV was an average of 62 

knots and 5702 ft from the intersection. There was more than sufficient lead time after 

the alert to stop the aircraft a safe distance from the intersection. 

4.2 Incursion Scenario 2 – Crossing Runway 

Ownship Departure / Traffic Arrival 

Scenario 2 involved the GV (ownship) taking off while the BE200 (traffic) was simulating 

a landing approach to a crossing runway. The BE200 was required to initiate a go-around 

at 200 ft AGL as a safeguard. The GV started its takeoff roll when the BE200 was less 

than 2 nm from the landing threshold. The GV evaluation pilot was trained to initiate an 

RTO upon receipt of the RCA. A runway conflict was considered to be in progress as soon 

as the GV started takeoff. Scenario 2 was tested only at Wallops. 

 Results for Wallops (Figure 4, Table 1): There were a total of 7 data runs for Scenario 

2. RSM issued RCA’s on all 7 runs. There were no late or false alerts. When the RCA 

was issued, the BE200 was about 1.6 nm from the landing threshold and the GV had 

just started takeoff with an average speed of 24 knots and had only moved a short 

distance, indicating that the conflict was detected very early. The RTO was initiated 

after the RCA when the GV was traveling at an average of 42 knots and was at a safe 

distance of over 5000 ft from the intersection. 

4.3 Incursion Scenario 3 – Crossing Runway 

Ownship Arrival / Traffic Departure 

During Scenario 3, the GV (ownship) was landing while the BE200 (traffic) was simulating 

a takeoff on a crossing runway. The GV evaluation pilot was trained to initiate a go-around 

upon receipt of the RCA. The timing conditions varied for each Scenario 3 test run 
21

depending on when the BE200 was released to begin takeoff. The timing differed 

considerably between Wallops and Reno test runs because of differing airport geometry. 

At Wallops, the BE200 was released when the GV was on final and approximately 1.5 nm 

from the threshold. As a result, the RCA occurred while the GV was still on final approach 

and a go-around maneuver was conducted. At Reno, the BE200 was released when the GV 

was past the threshold close to touch down. The GV evaluation pilot had the option of 

aborting the landing or landing and stopping before the intersection. The latter action was 

taken in all cases since the intersection was far enough from the touch down point to safely 

decelerate and stop before the intersection. For both Wallops and Reno, a runway conflict 

was considered to be in progress as soon as the BE200 started its takeoff roll. 

 Results for Wallops (Figure 5, Table 1): Out of a total of 22 data runs for Scenario 3 at 

Wallops, RSM issued RCA’s on 21 of those runs. No RCA was issued on one run 

because the BE200 did not start the simulated takeoff and there was no conflict. There 

were no late or false alerts. Based on the average of all runs, the RCA was issued when 

the GV was at an altitude of 296 ft AGL, 1.0 nm from the threshold and 1.9 nm from 

the intersection. The go-around was initiated at an average altitude of 214 ft AGL and 

0.6 nm from the threshold. When the conflict alert was issued, the ownship was far 

enough from the landing threshold to initiate a go-around in order to avert a conflict at 

the intersection of the crossing runway. 

 

 Results for Reno (Figure 11, Table 2): There were a total of 19 data runs for scenario 3 

at Reno. RSM issued RCA’s on 18 of those runs. No RCA was issued on one run due 

to significant problems with the GPS receiver on the BE200 that caused erroneous 

latitude and longitude positions. There were no late or false alerts. The RCA was 

always issued as soon as the BE200 started takeoff, at an average ground speed of 13 

knots. When the RCA occurred, the GV was just seconds from touch down at an 

altitude of approximately 25 ft AGL and an average distance of 5739 ft from the 

intersection. The pilot landed the aircraft and decelerated during rollout to a speed of 

less than 40 kt at an average distance of 1441 ft from the intersection. 

4.4 Incursion Scenario 4 – Crossing Runway 

Ownship Arrival / Traffic Arrival 

Both the GV and the BE200 were on final approach to intersecting runways during 

Scenario 4. The BE200 was required to initiate a go-around at 200 ft AGL. The GV 

evaluation pilot was trained to initiate a go-around upon receipt of the RCA or the GV 

safety pilot would initiate a go-around at 200 ft AGL if no RCA was issued. This scenario 

illustrated a flight condition not included in the formal FAA definition of incursion since 

both aircraft were airborne (see Section 1.0). However, the scenario would be considered a 

runway conflict based on ATC regulations for separation of arriving aircraft on crossing 

runways. Scenario 2 was tested only at Wallops. 

 Results for Wallops (Figure 6, Table 1): There were a total of 8 data runs for Scenario 

4. RSM issued RCA’s on all 8 runs with no late or false alerts. Based on the average 

for all runs, the RCA was issued when the BE200 was 1.2 nm from the traffic runway 

threshold at an altitude of 455 ft AGL, and the GV was 1.3 nm from the ownship 
22

runway threshold at an altitude of 516 ft AGL. The go-around was initiated by the GV 

after the RCA at an average altitude of 470 ft AGL and 1.2 nm from the threshold. 

Thus the RCA provided adequate lead time on all Scenario 4 runs to safely abort the 

landing and avert the possibility of a collision at the intersection of traffic’s arrival 

runway. 

4.5 Incursion Scenario 5 – Single Runway 

Ownship Taxi Crossing / Traffic Departure 

During Scenario 5, the GV was cleared to taxi across a runway on which the BE200 was to 

simulate a takeoff. When the GV was a specified distance from the hold line, the BE200 

was released to start a simulated takeoff in the same manner as for scenarios 1 and 3, 

creating a potential conflict if the GV did not stop at the hold line. This scenario was 

designed to test the look-ahead capability of RSM which enables the issuance of a conflict 

alert before the aircraft reaches the hold line, if there is a high probability that the aircraft 

could not or would not stop at the hold line. Scenario 5 was similar to the taxi/departure 

scenarios tested during the DFW flight test. During that flight test, the RCA was issued 

when the ownship taxied past the hold line and there was a conflict with arriving or 

departing traffic. However, during GVSITE the RCA was issued in time to stop the aircraft 

before reaching the hold line based on the deceleration characteristics of the ownship 

aircraft and the taxi speed. The faster the taxi speed, the farther the distance the alert would 

be issued before the hold line. To avoid false alerts, an alert was not issued if the aircraft 

was already slowing down enough to stop before the hold line. 

Timing the release of the BE200 for takeoff was difficult for this scenario. If the BE200 

was released too soon, there was no conflict because the BE200 had completed its takeoff 

roll before the GV was close enough to the hold line to issue the alert. Another difficulty 

with testing this scenario was that, in some cases, the GV evaluation pilot saw the BE200 

on the runway and took evasive action by braking and slowing down, causing the RCA to 

not be issued. When the timing was appropriate and the evaluation pilot did not anticipate 

the alert, RSM issued a conflict alert in time to stop the GV before the hold line. Due to the 

timing difficulties, RCA’s were not issued on some runs for this scenario at Reno. At 

Wallops timing was less of an issue and an alert was generated on every run for this 

scenario. 

 Results for Wallops (Figure 7, Table 1: There were a total of 7 data runs for Scenario 5 

at Wallops. RSM issued RCA’s on all 7 of those runs. There were no late or false 

alerts. Based on the average of all runs, the RCA was issued when the GV was 314 ft 

from the hold line taxiing at 19 kts, and the BE200 was on takeoff roll at 36 kts and 

1700 ft from the taxiway intersection. After the RCA, the evaluation pilot started 

braking and stopped the aircraft an average distance of 117 ft from the hold line. The 

testing for this scenario was highly successful since the alerts were always issued in 

time to stop the aircraft before the hold line. However, it could be argued that the 

alerting distance was too far from the hold line and might generate nuisance alerts 

during actual airport operations. For this reason, the RSM alerting parameters for this 

scenario are configurable for different airports and/or ownship aircraft. The parameters 
23

such as deceleration and other factors can be modified in the configuration file to vary 

the alert distance or turn off alerting (before the hold line) altogether. 

 Results for Reno (Figure 12, Table 2): There were a total of 11 data runs for Scenario 5 

at Reno. RSM issued RCA’s on 5 of those runs. Of the six runs that did not result in 

an alert, one was caused by erroneous position data and a bad GPS receiver on the 

BE200, as reported above for Reno scenario 3. The other five runs did not have RCA’s 

generated because of the timing issues described above. Timing was more difficult at 

Reno than at Wallops, possibly because Reno was the first flight evaluation and there 

was little experience, and because the distances were more difficult to estimate at Reno. 

In the worst cases, the BE200 was released too soon and had already finished the run 

before the GV was close enough to the hold line to get an alert. In other cases, the GV 

evaluation pilot saw the BE200 and started braking before the alert could occur. For 

these reasons, the non-alert runs are not considered missed alerts since they would be 

considered invalid or false alerts if they had been issued. For the runs in which alerts 

occurred, the RCA was issued when the GV was an average of 345 ft from the hold line 

or 515 ft from the edge of the runway, and the GV stopped 179 ft from the hold line. 

One false RCA was issued by RSM after a scenario 5 run had ended. The alert 

occurred when the GV was taxiing across the runway close behind the BE200 that was 

heading in the opposite direction. The false alert was a lesson learned that has resulted 

in changes to the alerting criteria, and the changes have been tested without further 

false alerting. 

4.6 Incursion Scenario 6 – Single Runway 

Ownship Takeoff Hold / Traffic Arrival 

During Scenario 6, the GV was holding in position for takeoff near the threshold while the 

BE200 was landing on the same runway. This scenario was only tested at Wallops. The 

BE200 was required to go-around by 200 ft AGL. The GV evaluation pilot was instructed 

to not maneuver the aircraft after receipt of the RCA. Scenario 6 was designed to test the 

capability to alert the holding aircraft as soon as possible of a conflict with traffic landing 

on the same runway. The RCA was issued when the BE200 was lined up with the runway 

on final approach to allow as much reaction time as possible for the GV on the runway. 

This scenario is an example of an incursion that occurred at Los Angeles International 

Airport (LAX) on August 19, 2004. A near collision occurred between a Southwest 

Airlines B-737 in position for takeoff and an Asiana Airlines B-747 landing on the same 

runway. The B-747 aborted landing procedures when close to the threshold and over flew 

the B-737. 

 Results for Wallops (Figure 8, Table 1): There were a total of 7 data runs for scenario 

6. RSM issued RCA’s on all 7 runs. There were no late or false alerts. Based on the 

average for all runs, the RCA was issued when the BE200 was 2.1 nm from the runway 

threshold at an altitude of 652 ft AGL. For the LAX incursion sited above, the GV 

represents the B-737 holding in position for takeoff and the BE200 represents the B747 on final. The RCA would have enabled the holding aircraft to clear the runway 

and/or contact ATC to divert the landing traffic in time to avoid this near collision. 
24

4.7 Incursion Scenario 7 – Single Runway 

Ownship Arrival / Traffic Takeoff Hold 

Scenario 7 was just the reverse of Scenario 6 but was staged differently at Wallops and 

Reno. At Wallops, the GV was on final approach while the BE200 was holding in position 

for takeoff near the threshold of the GV arrival runway. At Reno, the GV was on final 

approach and the NASA test van was parked in the overrun area behind the threshold of the 

arrival runway. At both Wallops and Reno, the GV evaluation pilot was trained to initiate a 

go-around upon receipt of the RCA. At Wallops, this scenario was designed to test the 

capability of RSM to alert the arriving ownship aircraft of a conflict with traffic holding for 

takeoff on the arrival runway. At Reno, the scenario was designed to test alerting for an 

object on the runway overrun. The RCA was issued when the GV was approximately 1.0 

nm from the threshold, based on the desired alerting position from previous flight and 

simulation testing. 

This scenario is another example of the LAX incursion sited above, but from the 

perspective of the arriving aircraft instead of the holding aircraft. The GV represents the B747 on final and the BE200 represents the B-737 holding for takeoff. The RCA would 

have allowed the arriving aircraft to abort the landing much earlier and not over fly the 

holding aircraft. Note that the conflict alerts do not occur at the same time for the holding 

aircraft and arriving aircraft. The holding aircraft receives the alert when the arriving 

aircraft is more than 2.0 nm from the threshold to allow as much time as possible to clear 

the runway and/or contact ATC. The arriving aircraft receives the alert at approximately 

1.0 nm from the threshold. The alerting distance from threshold for this scenario is 

modifiable in the RSM configuration file. 

 Results for Wallops (Figure 9, Table1): There were a total of 23 data runs for Scenario 

7 at Wallops. RSM issued RCA’s on 22 runs. An alert was not required on one run 

because the GV initiated a go-around above 700 ft AGL and about 2.0 nm from the 

threshold. There were no missed, late or false alerts. Based on the average for all runs, 

the RCA was issued when the GV was 0.9 nm from the runway threshold at an altitude 

of 304 ft AGL. The go-around was initiated at 0.7 nm and an altitude of 252 ft AGL. 

 

 Results for Reno (Figure 13, Table 2): There were a total of 19 data runs for Scenario 7 

at Reno. RSM issued RCA’s on 17 runs. RCA’s were not issued on two runs due to 

erroneous position data from the BE200 caused by GPS problems as reported for 

Scenarios 3 and 5 above. There were no missed, late or false alerts. RCA’s were 

issued consistently at an average altitude of 375 ft AGL and 5827 ft from the traffic 

parked in the overrun area of the arrival runway. Go-arounds were executed in 

response to the alerts at approximately 4965 ft from the traffic position and 329 ft AGL. 

Conflict alerts for this type of incursion were proven to be very effective and capable of 

preventing collisions on the runway. 
25

4.8 Performance Summary

Wallops: During the GVSITE testing, a total of 82 RIPS test runs were completed at 

Wallops by eight evaluation pilots. RCA’s were issued by RSM on all except two runs that 

were not conflicts due to scenario timing or pilot evasive action that precluded the RCA 

from being issued. There were no missed alerts and no late or false alerts. Although there 

were some problems with the updating of traffic data, there were no traffic errors that 

caused the conflict alert to not be issued. The timeliness of RSM alerts resulted in more 

than adequate lead time for pilots to take evasive action during the flight test. For the 

ownship departure Scenarios 1 and 2, with traffic departing or arriving on a crossing 

runway, RTO’s were executed based on RSM alerts when the GV was at a ground speed of 

between 24 and 65 knots and approximately 5000 ft from the intersection. The GV was 

able to decelerate and stop long before reaching the intersection. For ownship arrival 

Scenarios 3 and 4, with traffic departing or arriving on a crossing runway, go-arounds were 

executed based on RSM alerts when the GV was generally above 300 ft AGL and 0.9 to 1.3 

nm from the threshold. For the ownship taxi Scenario 5, the GV was able to be stopped 

before the hold line based on RSM alerts of conflicts with departing traffic. For Scenarios 

6 and 7, RSM RCA’s would eliminate the type of runway incursion that occurred at LAX 

in August 2004. 

Reno: A total of 60 RIPS test runs were completed at Reno by seven evaluation pilots. 

There were no missed alerts and no late alerts. There was one false alert that resulted in 

changes to criteria to prevent future occurrences. RCA’s were not issued by RSM on 9 

data runs, four of which were caused by erroneous traffic position data for the BE200 and 

five were the result of timing issues for Scenario 5 (Taxi / Departure). Conflict alerts 

issued by RSM were timely and consistent for all scenarios. 

The GVSITE flight test results at Wallops and Reno verify that the RSM algorithm 

performed consistently and effectively in detecting all runway incursions tested with a 100 

percent success rate. Runway conflict alerts issued by RSM were always timely, providing 

maximum lead time for evasive action. Flight testing at Reno and Wallops proved that the 

RSM algorithm, executing on board an aircraft with reliable and accurate traffic data, can 

significantly reduce or eliminate the safety hazards associated with runway incursions. 

4.9 Future Research and Development 

The successful performance of RSM has been verified by flight testing and simulation 

studies. However, the research accomplished to date has been based on medium and large 

commercial aviation operations. The next step is to adapt RIPS and RSM for general 

aviation (GA) operations. This includes modifications to the RSM conflict detection and 

alerting criteria as well as changes in RIPS alerting display concepts and pilot interface. 

RIPS will also be integrated with the Synthetic Vision GA display system and will be 

evaluated in simulation and in future flight tests. RSM will continue to be tested and 

improved through RIPS research at NASA Langley Research Center to accomplish the 

ultimate goal of eliminating runway incursions as the cause of aircraft accidents for all 

types of aircraft. 
26
27

ACKNOWLEDGMENTS

This work was performed under task order number SAMZ-4-SAM13RD0 for the Langley 

Research Center. The author wishes to thank Sharon D. Otero and Paul V. Hyer who, as 

fellow members of the Lockheed Martin development team, provided assistance, 

cooperation and the sharing of ideas in all phases of the RIPS/RSM project. 

REFERENCES

1. National Transportation Safety Board Safety Recommendation, A-00-66, July 6, 2000. 

2. Federal Aviation Administration, “FAA Runway Safety Report, August 2005”. 

3. Green, David F.: “Runway Safety Monitor Algorithm for Runway Incursion Detection 

and Alerting”, NASA/CR-2002-211416, January, 2002. 

4. Jones, D., Quach, C., and Young, S., "Runway Incursion Prevention System - 

Demonstration and Testing at the Dallas/Fort Worth International Airport", Proceedings of 

the 20th Digital Avionics Systems Conference, October, 2001. 

5. Jones, Denise R.: “Runway Incursion Prevention System Simulation Evaluation”, 

Proceedings of the 21st Digital Avionics Systems Conference, October 2002. 

6. Federal Aviation Administration Order 7110.65P, “Air Traffic Control”, February 19, 

2004. 
28

 Figure 1 – Reno Runway Incursion Zones 

 

 Figure 2 – Wallops Runway Incursion Zones 
29

RIPS WAL Scenario 1 – Runway 10

Crossing Runway – Departure/Departure

Ownship initiate RTO after RCA or by 80 kts,

stopping before 17-35 intersection

Traffic begins takeoff roll as ownship begins spool up,

Accelerate to then hold 45-50 kts as long as possible,

Conduct RTO, Stopping before 10-28 intersection

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 3 – WAL Scenario 1

 ___________________________________________________________________________

RIPS WAL Scenario 2 – Runway 10

Crossing Runway – Departure/Arrival

Ownship begins takeoff roll when 

traffic 1.25 NM from threshold, 

Initiate RTO after RCA or by 80 kts,

Stopping before 17-35 intersection

Traffic approach to Rwy 17 at 125 kts,

Initiate go-around at 200 ft AGL

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 4 – WAL Scenario 2
30

RIPS WAL Scenario 3 – Runway 10

Crossing Runway – Arrival/Departure

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

Traffic begins takeoff roll when ownship 1.5 NM 

from threshold, Accelerate to then hold 45-50 kts

for as long as possible, Conduct RTO, Stopping 

before 10-28 intersection

Ownship approach Rwy 10 at 138 kts,

Alerts occur when ownship > 200 ft AGL,

Ownship initiate go-around after RCA or by 200 ft AGL

 Figure 5 – WAL Scenario 3

 ____________________________________________________________________________ 

RIPS WAL Scenario 4 – Runway 28

Crossing Runway – Arrival/Arrival

Ownship approach to Rwy 28 at 138 kts,

Initiate go-around after RCA or at 200 ft AGL, 

remaining South of 10-28

Traffic approach to Rwy 22 at 125 kts,

Initiate go-around at 200 ft AGL,

remaining North of 10-28

Note: Both aircraft should be approximately 2 NM from threshold at same time

Alternate: none

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 6 – WAL Scenario 4
31

RIPS WAL Scenario 5 – Runway 10

Taxi Crossing/Departure

Traffic begins takeoff roll when ownship ~700 ft from 17-35,

Accelerate to and hold 45-50 kts, Conduct RTO, 

Begin decel when reach Rwy 10-28,

Stopping before taxiway A

Ownship taxi across hold line at

constant speed (at least 15 kts),

Stop after RCA, Safety Pilot to 

ensure stop before 17-35

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

Alternate: none

 Figure 7 – WAL Scenario 5

 

____________________________________________________________________ 

RIPS WAL Scenario 6 – Runway 10

Take-off Hold/Arrival

Ownship in position and holding

Subject not to maneuver aircraft after RCA

Traffic to use short final, Must be at least 2.5 NM 

from threshold until ownship in position and hold,

Initiate go-around at 200 ft AGL

RWY 4-22 CLOSED

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 8 – WAL Scenario 6
32

RIPS WAL Scenario 7A – Runway 10

Arrival/Take-off Hold

Ownship initiate go-around after RCA or by 200 ft AGL

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

Traffic in position and holding

RWY 4-22 CLOSED

 Figure 9 – WAL Scenario 7
33

RIPS RNO Scenario 1 – Runway 16R

Crossing Runway – Departure/Departure

Ownship initiate RTO after RCA or by 80 kts,

Stopping before runway 25

Traffic begins takeoff roll as ownship begins 

spool up, Accelerate to then hold 45-50 kts

as long as possible, Conduct RTO, 

Stopping before runway 16R

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 10 – RNO Scenario 1

____________________________________________________________________________ 

RIPS RNO Scenario 3 – Runway 16R

Crossing Runway – Arrival/Departure

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

Ownship approach Rwy 16R at 138 kts,

Alerts occur after ownship touchdown,

Stop before runway 25

Traffic begins takeoff roll when ownship 

10 ft from touchdown, 

Accelerate to then hold 45-50 kts as long 

as possible, Conduct RTO, 

Stopping before runway 16R

Alternate: None that enables alerts

after touchdown

 Figure 11 – RNO Scenario 3
34

RIPS RNO Scenario 5 – 16R

Taxi Crossing/Departure

Ownship taxiing on B,

Cleared to cross runway 25,

Ownship taxi across hold line at

constant speed (at least 15 kts),

Stop after RCA, Safety pilot to 

ensure stop before runway 25

Traffic begins takeoff roll as ownship 

reaches taxiway November,

Accelerate to then hold 45-50 kts,

Conduct RTO, Stopping before runway 16R

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location

 Figure 12 – RNO Scenario 5

RIPS RNO Scenario 7 – Runway 16R

Arrival/Take-off Hold

Ownship

Traffic (Be-200)

Traffic (SV-RV)

Conflict location Air to Ground WXR 

2100 Traffic Detection

Ownship initiate go-around after RCA or by 200 ft AGL

Traffic in position and holding,

Per RNO request, traffic must be

located in runway overrun area

 Figure 13 – RNO Scenario 7
35

 Figure 14 - RSM Algorithm High Level Flow Diagram 

Yes 

 Conflict(s) 

 Detected? 

Component 5: 

Process Conflict 

Data 

Component 3: 

Conflicts In 

Ownship Zone 

Component 4: 

Conflicts In 

Crossing Zones 

Set RSM No

Alert Data 

Write RSM 

Alert Data 

Read Ownship & 

Traffic Data 

Yes

No

 Incursion 

 Testing 

 Required? 

Component 2: 

Algorithm Setup 

and Test Status 

Component 1: 

RSM Main 

Clear RSM 

Alert Data 

RIPS Shared 

Memory 
36

 Target Æ

Ownship 

Taxi or 

Stationary 

Departure 

(Takeoff Roll, Climbout) 

 Arrival 

 (Approach/Land, Rollout) Fly-thru 

Taxi or Stationary YES 

 

 YES 

 

YES NO 

Departure 

(Pre-takeoff 

Takeoff Roll 

Climbout) 

YES YES YES YES

Arrival 

(Approach/Land 

Rollout) 

YES YES YES YES

Fly-thru NO YES YES NO 

 Figure 15 - Operational State Matrix for Single Runway Conflicts

Operational States Matrix for Conflicts on Single Runways 

Test Applicable Conflict Alert Criteria: YES/NO 

Conflict Alert Criteria for Single Runway Conflicts (not all inclusive):

(1) Dist to target closing 

(2) In takeoff or landing path 

(3) Separation < criterion 

(4) Distance to threshold < criterion 

(5) Takeoff/landing in same or opposite direction 

(6) Altitude AGL < (decision ht + criterion) 

(7) Distance from threshold to target < land rollout distance for aircraft 

(8) Vertical separation < criterion 

(9) Taxi/stationary not clear of runway 

(10) Taxi separation < criterion 

(11) Taxi speed > criterion 
37

 Target Æ

 In Crossing Zone 

 Ownship 

 

Taxi or 

Stationary 

Departure 

(Takeoff Roll, Climbout) 

Arrival 

(Approach/Land, Rollout) Fly-thru 

Taxi or Stationary NO YES YES 

 

NO 

Departure 

(Pre-takeoff, Takeoff Roll, 

Climbout) 

NO YES YES NO 

 

Arrival 

(Approach/Land, Rollout) 

NO YES YES NO 

Fly-thru 

NO YES YES NO 

 Figure 16 - Operational State Matrix for Crossing Zone Conflicts

Operational States Matrix for Conflicts in Crossing Runway Incursion Zones 

Test Applicable Conflict Alert Criteria: YES/NO

Conflict Alert Criteria for Crossing Zone Conflicts (not all inclusive):

(1) Traffic departure or arrival in crossing zone (traffic taxi/stationary and fly-thru not applicable) 

(2) Not past intersection 

(3) Airborne & not turning to avoid conflict 

(4) Distance to threshold < criterion 

(5) Distance to intersection < criterion 

(6) Dist from threshold to intersection < land rollout distance for aircraft 

(7) Conflict separation < criterion 

(8) Vertical separation < criterion 

(9) Altitude AGL < (decision ht + criterion) 

(10) Ownship taxi/fly-thru intersection of crossing zones (check single rwy criteria for both zones) 
38

 Figure 17a – Primary Flight Display Figure 17b – Electronic Moving Map 

 Figure 17c – Heads Up Display (HUD)
39

Table 1 – Overall RSM Performance Results For GVSITE Flight Test At Wal

Scenario 1 

Dep / Dep

Scenario 2 

Dep / Arr

Scenario 3 

Arr / Dep

Scenario 4 

Arr / Arr

Scenario 5 

Taxi / Dep

Scen

Hold 

Total Number of Test Runs 8 7 22 8 7 Num Runs With RCA 8 7 21 8 7 Num Missed Alerts / Late Alerts 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0 0 Num False Alerts 0 0 0 0 0 Num runs with no RCA due to errors in traffic data 0 0 0 0 0 Num runs with RCA n/a due to evasive action or scenario timing 0 0 1 0 0 RCA – Ownship Avg Dist from: Thres 750’ 

Intersec 4843’

Thres 349’ 

Intersec 5244’

Thres 1.0nm 

Intersec 1.9nm

Thres 1.3nm 

Intersec 1.4nm

Hold line 314’ 

Runway 459’ 

RCA – Traffic Avg Dist from: Start Pos 135’ 

Intersec 1689’

Thres 1.6nm 

Intersec 1.8nm

Start Pos 353’ 

Intersec 1471’

Thres 1.2nm 

Intersec 1.3nm

Thres 510’ 

Taxiway 1732’ Thres 

RCA – Avg ground speed (kts):  (For Departure or Taxi) 

Ownship 65kt 

Traffic 18kt Ownship 24kt Traffic 36kt na Ownship 19kt Traffic 36kt 

RCA – Avg Radar Alt (ft AGL):  (For Arrival) na Traffic 519’ Ownship 296’ Ownship 516’ Traffic 455’ na Traff OWNSHIP EVASIVE ACTION STOP TAXI  Ownship Avg Dist from: na na na na 

Hold line 117’ 

Runway 262’ 

RTO – Ownship Avg Dist from: Thres 967’ 

Intersec 4626’

Thres 482’ 

Intersec 5111’ na na na 

RTO – Ownship Avg grnd spd (kts) 78kt 42kt na na na TOGA – Ownship Avg Dist from: na na Thres 0.6nm Intersec 1.5nm Thres 1.2nm Intersec 1.3nm na TOGA – Ownship Avg Alt AGL: na na 214’ 470’ na  Thres = Runway Threshold Intersec = Intersection Dep = Departure Arr = Arrival TOGA = go-ar
40

 Table 2 – Overall RSM Performance Results For GVSITE Flight Test At Re

Scenario 1 

Dep / Dep

Scenario 3 

Arr / Dep

Scenario 5 

Taxi / Dep

Scenario 7 

Arr / Hold

Total Number of Test Runs 11 19 11 19 Num Runs With RCA 11 18 5 17 Num Missed Alerts / Late Alerts 0 / 0 0 / 0 0 / 0 0 / 0 Num False Alerts 0 0 1 0 Num runs with no RCA due to errors in traffic data 0 1 1 2 Num runs with RCA n/a due to evasive action or scenario timing 0 0 5 0 RCA – Ownship Avg Dist from: Thres 535’ 

Intersec 5872’

Thres 332’ 

Intersec 5739’

Hold line 345’ 

Runway 515’

Hold Position 

5827’ 

RCA – Traffic Avg Dist from: Start Pos 536’ 

Intersec 2793’

Start Pos 89’ 

Intersec 3201’

Start Pos 2183’ 

Taxiway 1616’ na 

RCA – Avg ground speed (kts):  (Departure or Taxi) 

Ownship 49kt 

Traffic 33kt Traffic 13kt Ownship 20kt Traffic 50kt na 

RCA: Ownship Avg Radar Alt (ft):  (Arrival) na 25’ AGL na 375’ AGL  OWNSHIP EVASIVE ACTION STOP TAXI  Ownship Avg Dist from: 

na 

na 

Hold line 179’ 

Runway 349’ 

na 

ROLLOUT DECEL to < 40 KT Ownship Avg Dist from: na 

Thres 3956’ 

Intersec 1451’ na na 

RTO – Ownship Avg Dist from: Thres 704’ 

Intersec 5702’ na na na 

RTO – Ownship Avg grnd spd (kts) 62kt na na na TOGA – Ownship Avg Dist from: na na na Hold Position 4965’ TOGA – Ownship Avg Alt AGL: na na na 329’ 

 Thres = Rwy Threshold Intersec = Intersection Dep = Departure Arr = Arrival TOGA = go
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

Contractor Report

 4. TITLE AND SUBTITLE

Runway Safety Monitor Algorithm for Single and Crossing Runway

Incursion Detection and Alerting

5a. CONTRACT NUMBER

NAS1-00135B

 6. AUTHOR(S)

Green, David F., Jr.

 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

10. SPONSOR/MONITOR'S ACRONYM(S)

NASA

13. SUPPLEMENTARY NOTES

Langley Technical Monitor: Denise R. Jones

An electronic version can be found at http://ntrs.nasa.gov

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified - Unlimited

Subject Category 03

Availability: NASA CASI (301) 621-0390

19a. NAME OF RESPONSIBLE PERSON

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

14. ABSTRACT

The Runway Safety Monitor (RSM) is an aircraft based algorithm for runway incursion detection and alerting that was

developed in support of NASA's Runway Incursion Prevention System (RIPS) research conducted under the NASA Aviation

Safety and Security Program's Synthetic Vision System project. The RSM algorithm provides warnings of runway incursions

in sufficient time for pilots to take evasive action and avoid accidents during landings, takeoffs or when taxiing on the

runway. The report documents the RSM software and describes in detail how RSM performs runway incursion detection and

alerting functions for NASA RIPS. The report also describes the RIPS flight tests conducted at the Reno/Tahoe International

Airport (RNO) and the Wallops Flight Facility (WAL) during July and August of 2004, and the RSM performance results and

lessons learned from those flight tests.

15. SUBJECT TERMS

Runway incursion; Flight test; Incursion alerts; Integrated display system; Runway incursion prevention system; Runway

safety monitor; Aviation safety; Synthetic vision

18. NUMBER

 OF 

 PAGES

45

19b. TELEPHONE NUMBER (Include area code)

(301) 621-0390

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

609866.02.07.07

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

NASA/CR-2006-214275

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- 02 - 2006