THE LAST 200 FEET A LOW - COST APPROACH TO LANDING AIRCRAFT IN ZERO - - PDF document

THE LAST 200 FEET – A LOW-COST APPROACH TO LANDING AIRCRAFT IN ZERO-ZERO CONDITIONS

William J. McDevitt III, The Pennsylvania State University, State College, Pennsylvania

Abstract

Current Federal Aviation Administration Category I Instrument Landing System approach minima are a 200-foot above ground level Decision Height and 2,400-foot Runway Visual Range. The pilot may not commence an approach if the reported conditions are below these minimums and may only continue an approach below the decision height if the runway environment is in sight. This presentation will show that technology exists today to allow a pilot to continue his approach below published decision height to touchdown without ever actually ‘seeing’ the runway environment outside of his cockpit. Onboard the aircraft, Global Positioning System enhanced by Wide Area Augmentation System typically provides instantaneous positional accuracy

• f less than one meter horizontally and 1.3 meters
• vertically. With this metric even the smallest aircraft

could determine its location in X, Y, and Z to well within a fraction of its own footprint. Using high-precision GPS surveying equipment to perform a real-time kinematic survey, airport runway locations can be determined with centimeter- level accuracy, making it conceivable to land an aircraft on a specific point on the runway to a very high degree of accuracy. Instrument flight with no outside visual cues imparts high levels of stress on the pilot. Landing an aircraft in zero-zero conditions would add significantly more stress. Synthetic Vision Systems that offer the pilot a high-fidelity representation of the outside world would lessen or preclude this stress. Many major universities, government agencies, and aerospace corporations are already at work to provide these type systems. SVS will most likely be initially designed for commercial, military, and business-class aircraft, and will cost tens to hundreds of thousands

• f dollars. This valuable and life-saving technology

will not be affordable to most general aviation pilots. This paper proposes a reduced-cost SVS system for general aviation, based

• n

a Microsoft Windows™-based tablet computer. This presentation will document the testing of this system under Visual Flight Rules conditions in order to quantify the achievable accuracy and characterize feasibility of the concept.

Introduction

The concept of landing an aircraft on instruments has been in existence since the late- 1930’s. Subsequently, the most common precision landing aid has been the Instrument Landing System (ILS). Most general aviation aircraft are equipped to perform only ILS Category I approaches with minima

• f a 200-foot Decision Height (DH) and 2,400-foot

Runway Visual Range (RVR). Decision Height is a specified height or altitude in the precision approach at which a missed approach must be initiated if the required visual reference, such as the runway markings or lights, to continue the approach have not been acquired [1]. RVR is the distance over which the pilot of an aircraft on the centerline of the runway can see the runway surface markings delineating the runway or identifying its center line [2]. While these minima may sound perfectly reasonable to the layman, in reality they may leave an aircraft in extremis if the destination weather conditions are below minimums and the aircraft is low on fuel with no suitable divert airfield. Precision approaches are aptly named; they allow the pilot to precisely know their location on the approach to landing in three dimensions, X (longitude), Y (latitude), and Z (altitude). For nearly 60 years, the ILS was the most accurate landing navigational aid available. But since the advent of the NavStar Global Positioning System (GPS) satellite constellation and Space-Based Augmentation Systems (SBAS) such as Wide Area Augmentation System (WAAS), there is now an alternative allowing a pilot to precisely know their location in relation to the airfield. While the WAAS specification is for a worst-case accuracy of 7.6 meters both horizontal and vertical, the actual measured accuracy of the system is routinely 0.9 meters lateral and 1.3 meters vertical in most of the

continental United States [3]. This level of accuracy would allow the pilot to know their location, even in the smallest aircraft, to well within the footprint of the aircraft. To accomplish a precision approach, not only does a pilot need to know the aircraft’s location in space, they need to acquire the airfield and accomplish the final approach to landing visually. But technologically, this may no longer be required. By using high-precision GPS surveying equipment to perform a real-time kinematic (RTK) survey, airport runways can be located with centimeter-level

• accuracy. This would make it conceivable to land an

aircraft on a specific point on the runway to a very high degree of precision by simply allowing a computer to calculate the vector between the aircraft and its intended touchdown point. While this may be technologically possible, a landing of this type with no outside visual cues would certainly impart high levels of stress on the pilot. The use of a Synthetic Vision System (SVS) that is tied to the GPS-WAAS-Touchdown Point calculation would offer the pilot a high-fidelity representation of the

• utside

world, significantly lessening

• r

precluding this stress. Many major universities, government agencies, and aerospace corporations are already at work to provide this type of system [4-10]. SVS will most likely be initially designed for commercial, military, and business-class aircraft, and will cost tens to hundreds of thousands of dollars. This valuable and potentially lifesaving technology will not be affordable to most general aviation pilots. Therefore, a reduced-cost SVS system for general aviation pilots displayed on a Windows™- based tablet computer is proposed. While a system

• f this sort could not provide awareness of airborne

traffic or runway incursions by vehicles or other aircraft without the addition of an ADS-B (Automatic Dependent Surveillance – Broadcast) system, in a life

• r death situation it could allow the pilot to land the

aircraft when all other options have been exhausted.

Approach

There are two major components to this system: a georeferenced terrain database and a synthetic vision display.

Terrain Database

To be effective, the terrain database must present a view that closely mimics the real world as viewed by the pilot. There are two major components to any terrain database: elevation data and imagery. Much of this data is now publically available through various government agencies (e.g. USGS or state or local government GIS sites) at no cost. Elevation data can be acquired in many forms, but most commonly as digital elevation models (DEM) or digital terrain elevation data (DTED) at various levels of resolution. The vast majority of the area in aviation-related terrain databases need only the coarsest levels of elevation post-spacing (90+ meters between posts). Only when nearing the ground on approach to landing would a higher resolution (sub-10 meter post spacing) data be

• required. To create a terrain database that can be

rendered by a computer, this data must be converted into polygonal surfaces that represent the surface of the earth. Site-specific satellite or aerial imagery is the second piece required to generate a convincing texture on the elevation surface. By using real imagery that is directly coordinated with the terrain data, the scene that is rendered by the software engine will have a very high degree of realism. Again, the vast majority of imagery used to create the database need not be of particularly high resolution; publically available 30-meter resolution Landsat 7 imagery would be more than sufficient for most flight

• regimes. Only on final approach to landing would

higher resolution imagery be justified. An alternative or enhancement to high- resolution imagery would be vector-based drawing features that could be inserted into the database, such as runways and runway markings for specific

• airports. The industry standard for these types of

features is the OpenFlight™ format from Presagis [10]. These features can be created and rendered in various modeling tools such as Autodesk 3ds Max or Presagis Creator. Creating runways and markings in this manner would allow a pseudo-high fidelity presentation of the airport without the added

• verhead of generating a terrain database using high-

resolution imagery that would vastly increase the size

• f the database.

The target airfield for this proposal is General William J. Fox Field (ICAO: KWJF) in Lancaster,

• California. Both 10-foot post-spacing DEM and

Digital Surface Models (DSM) were obtained from the Los Angeles County GIS Data Portal which provided part of the high-resolution elevation data required for the landing field. All other elevation data for the terrain database was 90-meter post- spacing Shuttle Radar Topography Mission (SRTM) data obtained from the University of Maryland (UM) Global Land Cover Facility (GLCF). One foot resolution aerial imagery of the field was also

• btained from the Los Angeles County GIS Data

Portal which was sufficient to produce a realistic display of the airport area in the database. All other imagery in the database was 30-meter resolution Landsat 7 Enhanced Thematic Mapper Plus (ETM+) data also obtained from the UM GLCF. To complete the need for high-resolution location data on the airfield itself, a civil-engineering grade GPS survey was taken of the runway surface to incorporate into the database as both an elevation source and a source for a vector drawing depiction of the runway surface and markings. This survey was accomplished with a Leica Viva GS/CS-15 Global Navigation Satellite System (GNSS) surveying system to obtain differential GPS real-time kinematic data as a basis for both high-fidelity elevation and location data of the runway surface itself. Database Creation Once all the required components for the terrain database were collected, the following process was used to compile them into a usable format (Figure 1).

• 1. The raw GPS survey data was imported

into Leica GeoOffice 8.2 for processing. The differential GPS base station location was post-processed through the National Geodetic Survey’s OPUS (Online Positioning User Service) website to provide a highly accurate base location for the survey. OPUS processing provides an overall RMS location of 3cm or less. The processed data was then exported as an ESRI shapefile.

• 2. The

OPUS-corrected base station location was used to precisely georeference the 1-foot resolution imagery of the airfield using the GlobalMapper 14 software package. This image was used as a reference in developing the vector runway and runway markings in Autodesk Civil 3D as well as becoming the high-resolution imagery portion of the final terrain database.

• 3. The shapefile produced in Step 1 was

imported into Autodesk Civil 3D as the basis for creating the vector runway and runway markings. The 1-foot resolution imagery of the airfield was also imported as a check on the exported GPS survey points and to aid in drawing the runway and markings. Runway markings were in accordance with standard Federal Aviation Administration (FAA) airport signage [11]. Once the drawing was completed, it was exported as a region in Civil 3D’s .dwg file format to be textured in Autodesk 3ds Max. Figure 1. Database Creation Work Flow

• 4. A

Delaunay triangulated irregular network (TIN) was created in Civil 3D from the GPS shapefile points. This was exported as an elevation GeoTIFF and used as the high-fidelity source for compiling the terrain database.

• 5. The Civil 3D .dwg file from Step 3 was

imported into 3ds Max to be textured. Striping and numbers were in accordance with FAA standards [11]. Once completed, the textured drawing was exported as an OpenFlight™ standard file (.flt) for use in the final terrain database as a vector drawing file.

• 6. All the data acquired or created to that

point was imported into ESRI ArcGIS 10.1 with the MetaVR Terrain Tools 1.2 plugin for final compilation. Terrain Tools takes the elevation or imagery source of the highest available resolution as it compiles the data into source tiles to be read by MetaVR Virtual Reality Scene Generator (VRSG) 5.7, the rendering engine of the Synthetic Vision System.

• 7. The last step in the process of creating

the terrain database was to process the OpenFlight™ file of the textured runway surface with MetaVR’s Curved Runway

• Model. This tool conforms the flat

vector runway drawings to the terrain elevation skin of database, completing the terrain database creation process.

Synthetic Vision System

The synthetic vision system is the heart of this

• proposal. It was hosted on a Windows™ 8-based

tablet computer (Microsoft Surface™ Pro) that was present in the cockpit of the test aircraft as an additional source of location and attitude reference. The rendering engine for the terrain database is MetaVR’s Virtual Reality Scene Generator (VRSG) v5.7. VRSG is a Microsoft DirectX™-based rendering engine that provides geospecific simulation as an image generator with game quality graphics [12]. A custom dynamically loaded library (.dll) provides the interface from the attitude-heading reference system (AHRS) that drives the location and eyepoint in VRSG to mimic the real world (Figure 2). Additionally, a 2D head-up display (HUD) overlay was interfaced with VRSG to provide dynamic latitude – longitude – altitude and roll – pitch – heading information from the AHRS on the tablet screen. Figure 2. WJF Runway 24 Final Approach View The AHRS unit is a low-cost, ArduPilot Mega (APM) -1 compatible micro-UAV controller. This unit, while very inexpensive (under $300), provides all the information required for this application: 3-axis gyro, 3-axis accelerometer, 3-axis magnetometer, barometric pressure sensor for altitude, 4MB of onboard memory, and WAAS- corrected GPS, with mini-USB output in a 3” x 1.5” x ¾” package (Figure 3). The unit is powered through the mini-USB port. Figure 3. APM-1 Attitude-Heading Reference System

This unit is primarily designed as an autopilot to convert radio-controlled model aircraft into fully functional and autonomous unmanned aerial vehicles (UAV). The hardware and software/firmware are all

• pen source.

Real-time Data Flow Real time positioning data flows from the AHRS to the SVS (Figure 4) in accordance with the following methodology:

• 1. The AHRS unit receives NMEA data

from the GPS receiver.

• 2. The AHRS unit outputs its data via USB

to the tablet using the MAVlink (Micro Air Vehicle link) binary communication protocol to the

• pen

source ArduPilotMega Mission Planner v1.2.

• 3. The Mission Planner software decodes

the MAVlink data (including latitude- longitude-altitude, roll-pitch-heading, GPS time, and GPS quality (among

• thers)) for its own use.
• 4. The Mission Planner software allows the

re-porting of the incoming data out to

• ther serial ports as ASCII data streams.

Open source com0com software was used to create two virtual serial (COM) ports connected by a virtual null modem.

• 5. The transmitted data is received by the

second COM port (COM5), where it is available to be read and parsed by the custom HUD.dll that creates the 2D HUD and drives the VRSG location and eyepoint. Figure 4. Real Time Data Flow

Test Methodology

Flight testing was performed with a Piper PA-28 Archer multi-place aircraft (Figure 5). Approaches were performed on the RNAV (GPS) Rwy 24 approach to Fox Field (Figure 6) in accordance with LNAV (Lateral Navigation) minima . Figure 5. Piper PA-28 Archer To characterize accuracy of approaches in visual conditions, data was collected for one approach and five landings with the SVS not in play. Cockpit video for out-of-the-windscreen views was recorded. VRSG has the ability to record the SVS screen while in flight. Video from the camera and the internal recording was time-synched and reviewed for latency and accuracy between the SVS and the real world. Once the pilot was comfortable flying the LPV approach, he was ‘foggled’ (training glasses that allow viewing the instrument panel but not out the windscreen) forcing him to fly only the SVS. While flying on foggles, a safety pilot cleared the runway and any traffic and ensured that the aircraft did not enter an unsafe flight regime. Additionally, all data was recorded with the ArduPilotMega Mission Planner’s data logging function and touchdown points were compared to an ideal point for all landings.

Figure 6. RNAV (GPS) RWY 24 approach, Fox Field CA

Test Points

To complete the testing, four 1-hour flights were

• anticipated. All flights included data recording of
• ut-of-the-cockpit video as well as internal video

recording of the SVS. Flight 1 (visual-only flying with no reference to the SVS)  One GPS approach to runway 24 or 6.  Five touch and go landings  Record the SVS display for latency determination Data review. Assess feasibility of:  Shooting approaches using SVS  Take off using SVS  Landing using SVS Flight 2  One GPS approach to runway 24 or 6 using SVS to 200 feet AGL - continue visual landing to a full stop. Take off using SVS as primary reference  One GPS approach to runway 24 or 6 using SVS to touchdown.  5 additional landings using SVS to touchdown Flight 3  Fly three touch and go landings at night with data and video recording using normal flight displays and instruments Data review. Assess feasibility of:  Shooting night approach using SVS  Night landing using SVS Flight 4  Fly one night GPS approach and landing using SVS as primary reference

Flight Test Results

Testing was accomplished over three days: July 13th, August 3rd, and August 10th, 2013. Both pilots flew on all three days. The left seat (safety) pilot had in excess of 14,000 total flight hours and over 2,000 hours in the Archer-type aircraft. The right seat (test) pilot had less than 250 total flight hours and less than 20 in type.

July 13 Test Day

On the first test day, two separate flights were accomplished, neither providing satisfactory results. Additionally, the cockpit mounting arrangements for both the AHRS/GPS and SVS tablet computer proved to be not substantial enough for continued flight and required a redesign. The initial flight was per the Flight 1 test points;

• ne GPS runway 24 approach to touchdown followed

by five touch-and-go landings in the visual pattern, all in VFR conditions. The aircraft was flown visually and the SVS actively recorded for post-flight

• comparison. After landing, a data review was

performed to determine the feasibility of continued flight using the SVS as a primary visual source. The data review of both the out-of-the-cockpit and SVS video demonstrated nominal performance with little to no latency in the SVS system. Even in very bright sunshine the SVS Surface™ tablet provided satisfactory brightness for viewing. Lastly, the X-Y (Lat/Long) portion of the GPS as well as the longitudinal pointing (heading) from the AHRS proved to be highly accurate. These were the successes of the first flight. Significant failures were in the Z (altitude) portion of the GPS feed and the roll return-to-level of the AHRS. Instead of a 1.3 meter vertical accuracy expected per the GPS/WAAS common measurement

• r even the 7.6 meter accuracy of the specification,

the test system displayed a relatively fast, random creep from approximately 100 feet below barometric altitude to nearly 200 feet above. The test team believed this to be caused by the WAAS augmentation not being enabled in the GPS unit. Unfortunately, the team was not equipped with the proper USB cable to connect directly to the GPS to determine this. Additionally, the AHRS roll portion was very slow returning to level when coming out of a right roll. When lined up on final approach, wings level, the AHRS/SVS was still showing 2.5 – 3 degrees of right roll for most of the approach. To determine if this condition was anomalous, a second flight was performed with identical results. The system used to mount the SVS and AHRS/GPS to the aircraft glare shield proved to be

• inadequate. The AHRS/GPS was attached to the

glare shield with adhesive-backed Velcro, but there was no level location within USB cable length of the tablet, causing some initial pitch issues with the SVS

• display. The mounting system for the SVS was

clamped directly to the aft edge of the glare shield, but the attachment point for the tablet was almost six inches aft of the clamp point. The weight of the tablet (2 pounds) on a six inch moment arm caused a significant droop in the entire mounting system. While workable, it was very flimsy and was deemed not substantial enough for continued flight. While the overall results for the day were unsatisfactory, the successes of the SVS location, pointing, brightness, and lack of latency were promising.

August 3 Test Day

Prior to the August 3rd test day, several corrections and enhancements were made to the

• system. In an effort to remove the slow return-to-

level roll rate and altitude errors, a new AHRS/GPS unit was acquired. The original AHRS was a first- generation unit and the test team postulated that a more current unit might fix these issues. The APM 1.0 AHRS and Mediatek MT3329 GPS were replaced with a state-of-the-art APM 2.6 AHRS and a uBlox LEA-6 GPS (Figure 7). The uBlox GPS has a significantly larger antenna and improved accuracy. Figure 7. APM 2.6 AHRS & uBlox LEA-6 GPS The SVS mounting system was completely redesigned to provide a level ground plane for the AHRS/GPS and a sturdier attach point for the SVS tablet (Figures 8 & 9). Figure 8. SVS and AHRS/GPS Mounting

Figure 9. AHRS/GPS Mounting Unfortunately,

• n

system startup ground elevation initialized to zero feet, meaning that the eyepoint of the SVS was 2330 feet below ground. Many hours of troubleshooting traced the issue to a change in the APM Mission Planner software. A software update that occurred between test days 1 and 2 changed the output altitude from Mean Sea Level (MSL) to Above Ground Level (AGL). As this AHRS/GPS unit is designed for radio-controlled scale aircraft, the software change was to support the community’s requirements. Generally, RC aircraft pilots are concerned with their altitude above the ground, not their altitude above sea level. By the time this discovery was made it was too late in the day to begin flying, so testing was postponed for a week.

August 10 Test Day

Prior to the August 10 test day, the HUD.dll code was changed to account for the MSL-AGL altitude issue discovered on August 3rd. In this case, the field elevation in meters was added to the AGL altitude feed coming from the APM Mission Planner, which in effect produced an MSL altitude. Successful ground initiation was followed by a repeat of the Flight 1 test points. As on the July 13 test day, the comparison of the cockpit video to the SVS showed no noticeable latency, good X-Y location, good longitudinal pointing, and good visibility in bright sunlight. Additionally, the Z error and the slow roll return-to-level had been corrected. Flight 2 test points were completed with no

• issues. It took the test pilot two approaches to

landing to become comfortable with the sight picture

• n the SVS. At that point he was foggled and made

four landings in quick succession, all to the centerline

• f the runway.

Figure 10. Flight 2 Test Points – Horizontal Accuracy

Figure 11. Flight 2 Test Points – Vertical Accuracy Figure 10 shows the horizontal accuracy of the Flight 2 (Day) test point landings. As can be seen, the test pilot had little difficulty with lineup despite having only a fixed center point crosshair on the

• SVS. The Course Deviation Indicator (CDI) was
• utside the test pilot’s field of view while flying the
• SVS. Maximum offset from centerline was 22 feet

right and average offset was 9.2 feet on a 150-foot wide runway. Figure 11 illustrates the vertical accuracy of the Flight 2 (Day) test points. The red line labeled “3 Deg Glideslope” represents an optimal approach angle to the touchdown point, 1000 feet from the runway threshold. As can be seen, the test pilot had more difficulty determining glideslope than lineup. Most approaches were high (average 28 feet) passing

• ver the touchdown point. Landing 1 was low for

second half of the approach with touchdown

• ccurring only 500 feet (instead of the targeted 1000

feet) from the threshold. Only Landing 2 occurred in the touchdown zone. As with the horizontal accuracy, the ILS glideslope indicator was outside the test pilot’s field of view while flying the SVS. The fixed center point crosshair on the SVS proved inadequate for proper glideslope control. Figure 12. Flights 3 &4 Test Points – Horizontal Accuracy

Figure 13. Flights 3 & 4 Test Points – Vertical Accuracy Overall, the Flight 2 test points demonstrated that there was an adequate margin of error while flying the SVS to accomplish safe landings, albeit long and short of the touchdown point. At no time did the safety pilot feel the need to take control of the aircraft or to terminate an approach that was deemed unsafe. The Flight 3 test points were accomplished in the 15 minutes before Nautical Twilight (30 minutes after sunset), and by this point the test pilot was so comfortable with the system it was decided to keep flying and accomplish the Flight 4 test points. Although only one night landing was called for, the test pilot accomplished three successful landings. Figure 12 shows the horizontal accuracy of the Flights 3 and 4 (night) test point landings. Again, the test pilot had little difficulty with lineup with a maximum offset of 7.5 feet from centerline and an average offset of 4.5 feet. This offset was substantially better than the day test landings and can probably be attributed to the pilot having more experience with the SVS. Figure 13 shows the vertical accuracy of the Flights 3 & 4 (night) test point landings. As was seen during the day test points, remaining on glideslope was much more difficult for the test pilot than was controlling lineup. Only one landing occurred in the touchdown zone, the four other approaches were an average of 35.3 feet high at the touchdown zone. Night Landing 4 was a missed approach initiated by the test pilot when he experienced a momentary loss

• f situational awareness. He quickly recovered and

proceeded to land the aircraft safely, on centerline, farther down the runway. Post-flight debriefing with the test pilot (a low- time pilot; less than 250 flight hours and less than 20 hours in type) noted the following quotations: “Once I got the sight picture of the SVS, it was pretty easy to land.” “Upgrading to full HUD symbology would make it even easier to land.” “If I can land on the centerline every time, it would be even easier for pilots with more experience.”

Overall Results

Even in its current rudimentary state, this SVS would allow a general aviation pilot to make an emergency safe landing in weather conditions that would normally preclude going below 200 feet AGL. From decision height (200 feet AGL) the glideslope is a standard 3°; the pilot can continue a normal rate of descent, on heading, and be assured of touching down on the runway. The SVS ensures that he can ‘see’ the runway and with its assistance, manually guide the aircraft to the center of the runway near the touchdown zone (1000 feet from the runway threshold). The intention of this system as presented is to allow an aircraft with no other option (delay for better weather conditions, no divert field available) to safely land, providing a possibly lifesaving tool for general aviation pilots. As a proof-of-concept, the SVS as presented in this paper was a success and warrants further scrutiny.

Acknowledgments

The author would like to thank MetaVR, Inc. for their assistance in providing the initial 2D HUD framework code that drives the eyepoint and is displayed on the SVS, and RuthAnn Abruzzi of Applied Research Associates for connecting it with the incoming data stream in this application.

Biography

Bill McDevitt is a 17-year employee of Science Applications International Corporation (SAIC) / Leidos where he is site manager and chief of mission planning on a classified UAV program. Mr. McDevitt was commissioned a U.S. Naval Flight Officer in 1984 and subsequently flew various carrier-based electronic warfare aircraft, primarily the EA-3B Skywarrior and the EA-6B Prowler. Since joining SAIC, Mr. McDevitt was instrumental in the successful operational test and deployment of the B-2A Spirit stealth bomber and has been in his current position for nine years. He is a recognized expert in combat mission planning and threat avoidance as well as developing virtual terrain databases for visualization of beyond line-of-sight UAV operations. He is a graduate of Villanova University (1984, BA – History) and Regis University (2005, MS – Computer Information Technology) and is currently completing his Master

• f Geographic Information Systems degree at the

Pennsylvania State University where he also received his Graduate Certificate in Geospatial Intelligence and was the co-winner of the USGIF-sponsored Michael P. Murphy Award in Geospatial Intelligence, both in 2011.

References

[1] Pilot/Controller Glossary - D. (2013, March 7). Retrieved April 6, 2013, from http://www.faa.gov/air_traffic/publications/atpubs/pc g/d.htm [2] Pilot/Controller Glossary - V. (2013, March 7). Retrieved April 6, 2013, from http://www.faa.gov/air_traffic/publications/atpubs/pc g/v.htm [3] WIDE-AREA AUGMENTATION SYSTEM PERFORMANCE ANALYSIS REPORT Report #43. (2013). Retrieved from FAA/William J. Hughes Technical Center, NSTB/WAAS T&E Team website: http://www.nstb.tc.faa.gov/REPORTS/waaspan43 .pdf [4] Jennings, C., A.K. Barrows, K. Alter, & J.D.

• Powell. 2000. Synthetic Vision Displays for

Instrument Landings and Traffic Awareness- Development and Flight Testing. Proceedings of the 19th Digital Avionics Systems Conference. IEEE.

• Vol. 1, pp. 2A2-1.

[5] Kramer, L.J., J.J. Arthur III, R.E. Bailey, & L.J. Prinzel III. 2005, May. Flight Testing an Integrated Synthetic Vision System. Defense and Security. International Society for Optics and Photonics. pp. 1-12. [6] Kramer, L.J., S.P. Williams. 2008, September. Testing the Efficacy of Synthetic Vision during Non- Normal Operations as an Enabling Technology for Equivalent Visual Operations. Proceedings of the Human Factors and Ergonomics Society Annual

• Meeting. SAGE Publications. Vol. 52, No. 19, pp.

1604-1608. [7] McKinley, J.B., E. Heidhausen, J.A. Cramer, & N.J. Krone Jr. 2008, April. Down-to-the-Runway Enhanced Flight Vision System (EFVS) Approach Test Results. SPIE Defense and Security

• Symposium. International Society for Optics and
• Photonics. pp. 69570J-69570J.

[8] MetaVR Visuals in FAA Synthetic Vision

• Simulators. (2013). Retrieved April 6, 2013, from

http://www.metavr.com/casestudies/FAA.html [9] Young, S.D., M.U. de Haag, & J. Sayre. 2003, September. Using X-band Weather Radar Measurements to Monitor the Integrity of Digital Elevation Models for Synthetic Vision Systems. Proceedings of SPIE. The International Society for Optical Engineering. Vol. 5081, pp. 66-76. [10] Hansen, A.J., W.G. Smith, & R.M. Rybacki. 1999, April. Real-Time Synthetic Vision Cockpit Display for General Aviation. Proceedings of SPIE. The International Society for Optical Engineering.

• Vol. 3691, pp. 70-80.

[11] AC 150/5340-1K - Standards for Airport

• Markings. (2010). Retrieved from Federal Aviation

Administration website: http://www.faa.gov/airports/resources/advisory_circu lars/index.cfm/go/document.current/documentNumbe r/150_5340-1 [12] MetaVR Virtual Reality Scene Generator (VRSG)™ - 3D Realtime Visualization. (2013). Retrieved April 6, 2013, from http://www.metavr.com/products/vrsg/vrsgoverview. html

32nd Digital Avionics Systems Conference October 6-10, 2013