Runway incursion prevention system-demonstration and testing at the Dallas/Fort Worth International Airport

A Runway Incursion Prevention System (RIPS) was tested at the Dallas-Fort Worth International Airport (DFW) in October 2000. The system integrated airborne and ground components to provide both pilots and controllers with enhanced situational awareness, supplemental guidance cues, a real-time display of traffic information, and warning of runway incursions in order to prevent runway incidents while also improving operational capability. A series of test runs was conducted using NASA's Boeing 757 research aircraft and a test van equipped to emulate an incurring aircraft. The system was also demonstrated to over 100 visitors from the aviation community. This paper gives an overview of the RIPS, DFW flight test activities, and quantitative and qualitative results of the testing.


Introduction
A runway incursion occurs any time an airplane, vehicle, person or object on the ground creates a collision hazard with an airplane that is taking off or landing at an airport under the supervision of air traffic control (ATC) [1]. Despite the best efforts of the FAA, National Transportation Safety Board (NTSB) and others, runway incursions continue to occur more frequently. The number of reported incursions rose from 186 in 1993 to 431 in 2000, an increase of 132 percent. In addition, there were 166 incursions during the first five months of 2001, compared with 158 during the same period in 2000. Runway incursions continue to be a serious aviation safety hazard, and have been listed on the NTSB's ten most wanted list of transportation safety improvements every year since its inception in 1990 [2]. The NTSB has also made a specific recommendation that the FAA require, at all airports with scheduled passenger service, a ground movement safety system that provides direct runway incursion warning capability to the flight crews [3].
The FAA has been developing a runway incursion alerting system for ATC since the early 1990s. Any alerts generated by this system would be relayed to flight crews by ATC via voice communications. Currently, there is no system available on-board aircraft to provide the flight crew with surface situational awareness information or timely alerts of potential runway conflicts.
As described in [4], the key to preventing runway incursions is to ensure that pilots know: ?? Where they are located ?? Where other traffic is located ?? Where to go on the airport surface In the event an incursion still occurs, by pilots not knowing the above, the flight crew and ATC should be alerted to the situation.
A Runway Incursion Prevention System (RIPS) has been developed to provide this knowledge in all visibility conditions. RIPS integrates airborne and ground-based technologies, which include flight deck displays, incursion alerting algorithms, on-board position determination systems, airport surveillance systems, and controller-pilot data link communications.
The RIPS concept was tested at DFW in October 2000. The objectives of the testing were to assess and validate technology performance and to demonstrate the system in an operational environment. RIPS is based upon a previous system that was designed to improve the safety and efficiency of aircraft movements on the airport surface [4]

Research Display Subsystem
The RIPS research flight deck displays were generated using a DFW airport geographic database [8] and inputs from position determination subsystems. The database was developed based on the requirements specified in [9].
A Head-up Display (HUD) was mounted in front of the left seat position of the B-757. The HUD was used for monitoring during final approach and tactical guidance during roll-out, turnoff, and taxi [10]. Symbology presented during landing was similar to that used by commercial HUD vendors and was implemented solely to show how this guidance could transition to surface guidance. During landing roll-out, deceleration guidance to a pilot-selected exit was provided along with centerline and runway edge symbology. During taxi, centerline and taxiway edge symbols were provided along with centerline tracking guidance to a gate location ( Figure 1). An additional capability during landing roll-out, was guidance to a hold-short point on the runway. All of the above were provided to enable all weather capability while reducing the likelihood of runway incursion by improving position awareness.

Figure 1. HUD Symbology During Taxi
An Electronic Moving Map (EMM) was displayed on the multifunction display when selected by the pilot. The EMM showed the airport layout graphically along with current position of the ownship, current positions of other traffic, and ATC instructions ( Figure 2). Several zoom/scale levels were available to pilots. ATC instructions received via data link were depicted both graphically and textually. The text messages were shown on a popup window that the pilot could remove if desired. Graphic depictions of ATC instructions included the approved route and any hold-short locations. Finally, any runway intersection that was ahead of high-speed runway traffic was highlighted to warn taxiing pilots of this situation. The EMM was provided to enable all weather capability while reducing the likelihood of runway incursion by improving awareness of position, traffic, and routing constraints.

Runway Incursion Alerting
At DFW, a runway was monitored for a runway incursion anytime the ownship was to enter the runway, e.g. during final approach and landing, takeoff roll, and taxi crossing. If an incursion occurred, alerts were provided to the flight crew. The alerts were generated by three methods: The RSM onboard incursion detection algorithm [11] took a generic approach for generating incursion alerts and was not designed for specific incursion scenarios. The RSM monitored traffic that entered a three-dimensional virtual protection zone around a runway that was being used by the ownship. The protection zone extended 1.1 nautical miles from the runway threshold, 220 feet from the edges of the runway, and 400 feet vertically. Detection of incursions was based on the operational state of the ownship and traffic and other criteria (separation and closure rate) to avoid false alerts. The identification, position, and altitude data was used to track the traffic in the protection zone. Velocity and heading information was calculated from position reports since the data provided by the surveillance system was not reliable. RSM generated Runway Conflict Alerts (RCA) (see below for definition).
The RIAAS onboard alerting algorithm [12][13] worked on the same general premise as the RSM, utilizing runway zones and tracking of traffic within that zone. However, RIAAS differed from RSM as follows. RIAAS issued alerts based on the states of ownship and traffic and criteria associated with specific scenarios. State was determined by the location relative to the runway, speed, track angle, and acceleration. RIAAS was designed to handle over forty specific runway incursion scenarios. RIAAS generated two types of alerts that are analogous to the Traffic Alert and Collision Avoidance System (TCAS) approach. A Runway Traffic Alert (RTA) cautioned the flight crew of a potential incursion or an incursion where the conflict did not yet require evasive action. The crew could take evasive action, however, at their discretion. An RCA occurred when an actual runway incursion was detected and an evasive action was required to avoid a potential collision.
The FAA ground-based surveillance system generated alerts of potential collisions on runways based on a subset of scenarios used by the Airport Movement Area Safety System (AMASS). AMASS is designed to alert air traffic controllers of surface conflicts. The safety logic was only applied to traffic that was on the runway or in its approach corridor. Alerts were generated when two targets fell within a separation distance threshold. These GBS alerts were transmitted to the B-757 as Flight Information Services -Broadcast (FIS-B) messages over a UAT data link [14]. GBS generated RCA alerts.
These three methods are currently designed to provide only alerting to the flight crew. Maneuver guidance for taking evasive action is not provided.
The alerts were presented to the flight crew both visually (on the HUD and EMM) and audibly. For a RTA, an audible enunciation of the phrase "Runway Traffic, Runway Traffic" was made in the flight deck. The textual form of this alert was presented on both the HUD and the EMM (in yellow). On the EMM, the traffic symbol representing the incurring aircraft/vehicle changed color (yellow). For a RCA (Figure 3), "Runway Conflict, Runway Conflict" was used for the audible alert. The textual form of this alert was presented on the HUD and the EMM (in red). On the EMM, the traffic symbol representing the incurring aircraft/vehicle changed color (red). For both a RTA and RCA, information was added beneath the ownship symbol and on the HUD indicating the distance to the incurring traffic and time until potential collision at present conditions. The identification tags were also highlighted.

Controller-Pilot Data Link Communications
A Controller-Communication and Situational Awareness Tool (C-CAST) enabled Controller-Pilot Data Link Communications (CPDLC). C-CAST was designed to provide improved situational awareness to ATC [15]. A test controller was shown a graphic display of DFW overlayed with real-time airport traffic and identification ( Figure  4). The test controller monitored DFW ATC. Any instructions for the research aircraft were spoken by the test controller into the C-CAST voice recognition system [16]. C-CAST also had touch screen capability. Instructions were encoded into ICAO Aeronautical Telecommunications Network (ATN) type messages and transmitted to the B-757 via VHF data link (VDL)-Mode 2 for display in the flight deck [17].
In addition, runway incursion alerts generated on-board the B-757 were sent to the C-CAST via the same two-way VDL Mode 2 data link for display to the controller. The alerts generated by the GBS were also displayed on C-CAST.
Route deviations were detected by RIPS on the B-757 if the aircraft left its assigned path during taxi. Route deviation alerts were data linked to C-CAST so that corrective action could be taken before the blunder lead to an incursion.

Position Sources
Ownship Position Determination A Local Area Augmentation System (LAAS) was installed at DFW to support both surveillance and guidance functions [18] [19]. The LAAS consisted of four independent GPS reference receivers on the airport to monitor the performance and health of the GPS signal. LAAS differential corrections were transmitted to the B-757 over a VHF Data Broadcast (VDB) data link.
Throughout most of the RIPS testing, LAAS position blended with inertial navigation system (INS) data was used for ownship position determination. In instances where the LAAS data was deemed inaccurate, differentially corrected position information from an AshTech GPS system with its own reference receiver was used.
A Wide Area Augmentation System (WAAS) receiver was also installed on the research aircraft. The WAAS is based on a network of approximately 25 ground reference stations located throughout the United States. Differential corrections are broadcast using satellites. The WAAS data was recorded onboard the research aircraft for post test analysis and was not used for real-time positioning during the RIPS testing.

Traffic Position Determination
RIPS used two methods of acquiring traffic position data onboard the research aircraft: ADS-B and Surface Traffic Information Services -Broadcast (STIS-B). The STIS-B data was sent from the ground system and is described in the Surveillance System section below.
ADS-B is a method of broadcasting data between aircraft and surface vehicles directly, without the use of ground-based equipment. For RIPS, ADS-B messages were broadcast from the research aircraft and test van at 1090 MHz using the Mode S extended squitter format. The messages contained position, altitude, speed, heading, air/ground status, navigation uncertainty, flight identification, aircraft ICAO address, and aircraft type. The position information was obtained from a GPS receiver using LAAS differential corrections. Position messages were transmitted at a normal rate of twice per second. [19]

Surveillance System
The FAA RIRP installed an experimental surveillance system at DFW [20] [21]. This system acquired information on traffic in the airport terminal area from several sources, fused this information, and then transmitted this traffic data to the NASA research aircraft.
The Airport Surface Detection Equipment (ASDE-3) radar captured position data (range and azimuth) at a 1 Hz rate for all aircraft or vehicles operating on the airport surface movement area. ASDE-3 does not require any equipage on aircraft or vehicles. It operates in the Ku-band (15.7 -16.2 GHz) and penetrates rain, snow, and fog to provide controllers with a high-resolution display of airport traffic. Although the ASDE-3 is a high performance radar system, it still has certain limitations. Complete airport surface coverage is not achieved with the ASDE-3 alone since it is a line-of-sight radar. False targets can be reported from multi-path reflections. Also, the ADSE-3 does not report target identification information.
An Airport Target Identification System (ATIDS) was installed on the east side of the DFW airport. ATIDS is a multilateration system designed to track and provide identification information for aircraft and ground vehicles with operating 1090 MHz ADS-B, Mode S, and ATCRBS transponders. The ADS-B transmissions from the research aircraft and test van were also captured by ATIDS.
A surveillance server provided position reports from the ASDE-3 radar and ATIDS, as well as, other ATC radar systems and taxiway sensor technology. These sources of position data were fused to provide seamless surveillance of the airport surface. These fused reports were sent to a data link manager to be packaged for transmission over the UAT RF data link (966 MHz) [14]. The UAT broadcast STIS-B messages to the B-757. The traffic data was also provided to the C-CAST via a local area network for display to the controller.

Flight Test Operations
The deployment to DFW occurred during September and October 2000. This testing included a check-out period, data collection period, and demonstration period.

Test Scenarios
There were four scenarios tested at DFW as described below. For each scenario, the test pilot was not required to take evasive action when a RTA was issued.

Scenario 1
The B-757 aircraft was landing with autoland engaged while the test van was located behind the hold line at a taxiway near the runway threshold. When the aircraft was approximately one nautical mile from the threshold, the test van began crossing the runway. The pilot was required to perform a go-around when either a RCA was issued or the aircraft reached 150 ft. above ground level (AGL). The test van continued across the runway.

Scenario 2
This was a departure scenario. Initially, the test van was located behind the hold line at a taxiway at the far end of the runway. Once the B-757 began its take-off roll, the test van began crossing the runway. The pilot was required to perform a rejected takeoff when either a RCA was issued or the aircraft reached 100 kts ground speed. The test van continued across the runway.

Scenario 3
For this scenario, the B-757 was the incurring vehicle and the test van was emulating an aircraft on departure. The B-757 was holding at a taxiway at one end of the runway. The test van began its "take-off" roll from the opposite end of the runway. Once the van reached 70 mph, the B-757 was cleared to cross the runway. When a RCA was issued, the B-757 was to stop and the van was to exit the runway.

Scenario 4
The B-757 aircraft was landing with autoland engaged. When the aircraft was approximately one nautical mile from the threshold, the test van entered the runway mid-field and began traveling down the runway, accelerating to 70 mph, away from the B-757 as if it was a departing aircraft. The pilot was required to perform a go-around when either a RCA was issued or the aircraft reached 150 ft. AGL. The van exited the runway at the far end.

Test Matrix
The test matrix consisted of four control variables: subject pilot (1-4), surveillance source (STIS-B only (without inclusion of ADS-B in the data fusion) or STIS-B and ADS-B), scenario (1)(2)(3)(4), and alerting algorithm used to drive the displays (RSM, RIAAS, GBS). The test runs were conducted at night to avoid impacting DFW operations. The RIPS runs were mixed with normal taxi operations and runs evaluating guidance to a hold-short point on the runway. This was done so the pilots would not expect an incursion alert on each test run. A total of 47 RIPS test runs were completed using 4 commercial B-757/B-767 captains as test subjects.

Data Collection
During the testing, data was taken in several formats. Subject pilots completed questionnaires to obtain their expert, albeit subjective, opinion of the system as implemented at DFW. Also, audio/video recordings of all camera images and the experimental displays were made of each test run for post test review. Finally, digital data was recorded onboard the B-757 and by the various ground systems. All digital data was time stamped using the GPS time reference.

Results
A summary of quantitative and qualitative results are presented. See the referenced reports for more detailed results.

Incursion Algorithm Performance
While completing the test matrix, data was collected on each of the three incursion alerting methods during each test run, however, only one method was chosen to drive the flight deck displays for each run. Table 1 shows the overall performance of each of the alerting methods. All of the missed alerts for RSM and RIAAS were a direct result of erroneous or missing traffic data from the STIS-B and/or ADS-B sources. It should be noted that during the testing, RSM was scanning all traffic for potential conflict while RIAAS was only tracking the test van. For GBS, the missed alerts were the result of the GBS alerting criteria and scenario timing. GBS safety logic was only applied to traffic that was on the runway or in its approach corridor, whereas, both RSM and RIAAS tracked traffic that had crossed the runway hold bar or was in the approach corridor. For the approach scenarios ( Figure 5), generally the RIAAS RTA occurred a few seconds before the RSM alert. Usually eight to 10 seconds later, the GBS alert was generated. The RIAAS RCA would then occur five (Scenario 1) to 15 (Scenario 4) seconds after that. During the first two days of testing, the GBS was not generating alerts on the approach scenarios before the requirements were met to conduct the go-around maneuver. The criteria was changed to expand the zone from 0.5 nautical miles from the runway threshold to one nautical mile out which then resulted in generation of alerts. This would suggest that at least some of the AMASS alerts generated for controllers do not occur in sufficient time to alert the flight crew and enable safe evasive action.
For the departure scenarios, the RIAAS RTA was generated first, followed usually one to five seconds later by a RIAAS RCA. The RSM alert was generated approximately the same time as the RIAAS RCA. Finally, the GBS would alert 10 to 20 seconds later.

Figure 5. Scenario 1 Alert Timing (from [22])
From Table 1, RSM generated four false alerts which were caused by multiple STIS-B ownship position reports. RIAAS generated 2 false alerts that were the result of erroneous traffic data. GBS generated 9 false alerts that were mostly caused by a time out alert on an errant target.

Navigation Subsystem Performance
As determined in [23], at the large airports, the navigation system accuracy should be no worse than 2.2m (95% horizontal circular error probability (CEP)) for safe operations on the surface movement area in low visibility conditions. Using the RIPS concept in extremely low visibility, this budget must account for not only the positioning system accuracy, but also the airport database accuracy (centerlines) and flight technical error (FTE). For DFW, the airport database accuracy for centerline data was specified to be one foot (0.3m). FTE was not assessed.
For positioning system performance analysis, truth data was obtained by post-processing GPS data using a well established carrier-phase interferometry technique that is often used in the surveying practice.
A preliminary assessment of the accuracy achieved suggests a 95% horizontal CEP (??) of 4.48 and 2.61 meters for WAAS and LAAS, respectively. The LAAS performance was nearly equivalent to performance of a Special Category I (SCAT-1) DGPS system used during trials in Altanta in 1997 [4]. Detailed results can be found in [24].
Availability was found to be 92.08% and 95.05% for WAAS and LAAS respectively. LAAS solutions were integrated with the INS to improve availability (to 98.32%), reduce variance, and provide the high update rate needed for display.

Traffic Reporting Subsystem Performance
Detailed assessment of the DFW surveillance system sensors, as implemented by the FAA, are described in [20]. Key metrics and the measured performance are listed in Table 2. The performance shown is a representative subset of all data and was taken while the test aircraft was stationary. As can be seen, the ATIDS outperformed the ASDE-3 with respect to accuracy and update rate. However, ATIDS did not provide complete coverage. Fusion enabled full coverage and consistent updating, while sacrificing some of ATIDS accuracy. Requirements of 12m and 1 Hz have been suggested in [25] for accuracy and update rate, respectively, for airport surface surveillance.
The other component of the traffic reporting subsystem of RIPS is the data exchange between aircraft (or the test van) via ADS-B and between the airport facility and the aircraft via STIS-B. The performance of these two links are summarized in Table 3. In general, the ADS-B link reliability [19] was very good when the research aircraft was airborne. When both test vehicles were on the surface, however, performance was degraded due to line of sight and multipath effects. This could be avoided or reduced by a more careful selection of antennas and antenna locations. During the testing, both transponder antennas were located at the rear of the test van. By placing one antenna near the front and one near the rear of the van, ADS-B performance for scenario 3 would be greatly improved by eliminating the null pattern in front of the van. Table 4 summarizes the percentage of position messages received onboard the B-757 during the demonstration period. The percentages shown are an average for two sorties conducted each demonstration night. Only scenarios 1 and 3 were conducted during the demonstration period.
ADS-B position messages were transmitted from the test van at 2 Hz. Typically for the airborne scenarios, the ADS-B position messages were received between 2 Hz and 0.5 Hz, with most messages being received at 2 Hz as specified. When the aircraft was on the ground (particularly for scenario 3), however, the rate at which the position messages were received was very erratic, ranging from 2 Hz to 0.1 Hz. This is most likely due to the line of sight issue.
Although not analyzed, ADS-B latency was observed to be very small (<1 sec). This was because ADS-B transmissions consisted of only encoding and decoding the message and propagating it over the RF channel.
The measured performance of the traffic reporting technologies tested at DFW do meet many of the current requirements for surveillance on the airport surface [25]. However, this is apparently not sufficient for a robust runway incursion alerting function within RIPS. This assessment is based on the observed rates of false alerts and missed detections. All false alerts and missed detections at DFW were traced to traffic data that was inaccurate, inconsistent, and/or not received in a timely manner. Further work will seek to establish the requirements for traffic reporting that are needed to support the incursion alerting function of RIPS.

Qualitative Results
Validating the feasibility of the system concept has been accomplished, in part, by obtaining qualitative questionnaire data and comments from the subject pilots during the data collection runs.
All of the subject pilots were complimentary of the RIPS tested at DFW. The pilots stated that the system has the potential to reduce or eliminate runway incursions, although human factors issues must still be resolved. Several suggestions were made regarding the alerting symbology which will be incorporated into future simulation studies. The audible alert was the first display to bring the pilots' attention to the incursion. The EMM would generally be viewed by the non-flying pilot at the time of an incursion since the flying pilot would remain heads up. The pilots stated that two-stage alerting was not necessary and they would take action on the first alert regardless. This may be related to the fact that this was a single pilot operation and the subject pilot did not have the benefit of co-pilot support. In general, after an incursion alert was received, the subject pilots stated they would not want maneuver guidance during final approach or takeoff roll but would like guidance on whether to stop or continue when taxiing across a runway. All of the pilots stated that, in general, the onboard alerts were generated in a timely manner, allowing sufficient time to react to the potential conflict. They all felt safer with RIPS onboard.

Summary
The Runway Incursion Prevention system tested at DFW demonstrated the potential to reduce or eliminate runway incursions. By providing supplemental guidance, surface situational awareness, and incursion alerts to both pilots and controllers, runway collisions can be prevented while also increasing the efficiency of airport surface operations.
Lessons learned with respect to the incursion detection function of RIPS can be summarized by the following points: ?? It is essential that reliable, timely, and accurate traffic data be available to enable optimum onboard incursion detection ?? Uplink of AMASS-generated alerts is not recommended due to the latencies involved and AMASS alert criteria ?? Further work should focus on the requirements for traffic information reporting to support the detection function Finally, the authors would like to point out that all equipment used during the DFW testing was prototype in nature. In other words, it is likely that production units would perform significantly better than the prototype versions.