Abstract
The Traffic Aware Planner (TAP) is a decision support automation tool for trajectory planning and optimization intended for use on today's flight deck. Drawing from a variety of on-and off-board data sources, TAP employs a sophisticated trajectory optimization algorithm that provides the aircrew with fuel-and time-saving reroute recommendations that are free of known conflicts with traffic, special use airspace, and severe convective weather. As this kind of weather is a significant part of the pilot's decision-making process while planning trajectory changes en route, a series of investigations has been conducted into the integration of weather data and associated functionality into the TAP software. This paper reviews the weather data sources and functionality that have been incorporated into TAP to date, along with experience gathered in the course of the design process. I.
Introduction
Traffic Aware Strategic Aircrew Requests (TASAR) is an operational concept developed by the National Aeronautics and Space Administration (NASA) for airborne route optimization and flight efficiency [1, 2] . TASAR provides the aircrew with a decision support automation tool that leverages a growing number of information sources on the flight deck to make fuel-and time-saving route optimization recommendations while en route. These suggestions can then be used by the aircrew to make better route change requests to air traffic control (ATC) under normal instrument flight rules operations. Since TASAR is a concept intended for the current operational environment [3] , it is intentionally designed to have no safety-critical impact or require any changes to current Federal Aviation Administration (FAA) rules or procedures [4, 5] .
The Traffic Aware Planner (TAP) software application is a research prototype tool for flight optimization developed by NASA that enables the TASAR concept [6] . TAP is a cross-platform application designed to run on low-cost electronic flight bag (EFB) platforms, such as the Apple iPad, along with other supporting avionics processors. TAP relies on a secure, receive-only connection from the onboard avionics via an aircraft interface device that provides ownship state and trajectory data as well as information from nearby traffic via Automatic Dependent Surveillance−Broadcast (ADS-B). Additionally, TAP connects to ground-based data sources via an airborne internet connection to obtain up-to-date information about external factors, including wind, special use airspace (SUA), and convective weather. TAP leverages this growing trend in cockpit connectivity to provide wind-optimal route and altitude change recommendations to the aircrew that are free of known traffic, airspace, and convective weather conflicts. These recommendations are computed based on a user-selectable optimization objective to minimize fuel burn, flight time, or a trip cost weighting fuel and time through a specified cost index.
Although TASAR was originally conceived as a traffic-aware application to incentivize ADS-B IN equipage by aircraft operators, the integration of weather data has been noted as a key factor in realizing the full potential of the concept by its users. Pilots encounter weather every day in the National Airspace System. Convective weather and turbulence are significant factors in pre-departure flight planning as well as when requesting en route trajectory changes. Today, airline dispatchers and FAA traffic managers make significant efforts to route aircraft around severe weather based on the best long-range forecasts available at the time of planning. However, the weather situation has often changed substantially once a flight is airborne. Thus, there are potentially significant time and fuel savings to be realized by the aircrew using a route optimization tool that takes advantage of the most up-to-date weather information while in flight. This paper reviews the status and history of weather integration efforts into TAP, including human-in-the-loop simulation evaluations [7] , in-flight testing on two different aircraft [8] [9] [10] [11] , as well as an operational evaluation with Alaska Airlines [12, 13] . This includes the current and proposed weather data sources used by TAP and their implications to its optimization algorithms, as well as the human-machine interface for weather information display and lessons learned regarding its usability.
II. Background
The core principle of TASAR is to provide fuel-and time-saving reroute recommendations that are useful to the aircrew and have a greater likelihood of acceptance when requested from ATC. In this way, the concept provides business case benefits to the airline operator by recommending optimal trajectory changes based on the timely information available while airborne compared to the information that was available when the flight plan was generated hours before takeoff. Additionally, because the trajectory recommendations are checked for conflicts with known traffic and other airspace constraints, requests made by the aircrew to ATC are more appropriate, thereby providing a potential to improve the efficiency of air traffic operations by minimizing the time spent on unapprovable requests.
A. Traffic Aware Planner
A simplified overview of the TAP system along with its primary data sources is depicted in Fig. 1 . The TAP system consists of several software components that reside onboard the aircraft, the most significant of which are the TAP Engine, the TAP Display, and the External Data Server. A high-level summary is presented here, and the reader is directed to Ref. 6 for a thorough description of TAP and its implementation.
The TAP Engine is the main processor of TAP. Using data sources from onboard avionics as well as external sources, the Engine performs all processing necessary to generate trajectory solutions, as well as respond to user commands received from the TAP Display that affect processing. Its core functionality consists of a trajectory generator coupled to a pattern-based genetic algorithm that creates wind-optimal candidate trajectory solutions, which are then passed through a conflict probe that filters candidate solution for known conflicts with traffic, SUA, and weather hazards.
The TAP Display, also referred to as the TAP Human-Machine Interface (HMI), facilitates the two-way interaction between the pilot and the TAP Engine. It displays TAP's automatically generated solutions, the time and fuel outcomes for those solutions, and any relevant conflict information. The Display also depicts SUA, wind, and convective weather features in order to provide context for TAP's solutions and foster trust in the automation system. It also accepts user inputs, such as the optimization objective for automatic route generation.
The External Data Server (EDS) handles the downloading and pre-processing of data from ground-based sources, such as winds, convective weather, and SUA data, via an airborne internet connection. In the long-term, EDS is envisioned as a flexible interface that could be expanded to a wide variety of other data sources via the internet, providing a growth path for continuous enhancement of TAP's functionality.
In addition to the primary TAP components installed onboard the aircraft, NASA has also developed other prototype weather processors in order to facilitate the development and evaluation of TAP's weather functionality. These components are the Ground Data Server and the Airborne Weather Radar Processor, which are discussed in subsequent sections. 
B. Weather Data in the Traffic Aware Planner
The first weather data source incorporated into TAP was wind (described in Section III), which is essential for aviation flight planning and trajectory prediction. Typically, flights are planned using the best wind forecasts available at planning time, which may be several hours before departure. Because the winds can be expected to change after the original flight plan is created and over the course of the flight once airborne, TAP's trajectory optimizations are improved by the incorporation of up-to-date wind forecasts obtained via the airborne internet compared to the predeparture wind forecast. This is especially true for long-haul flights, where the cumulative impact of wind prediction uncertainty can be substantial.
Additionally, TAP uses a three-dimensional (3D) wind grid that provides greater prediction accuracy compared to the limited set of winds specified at certain locations along the route that is employed in a typical flight management system. This is especially important when generating reroutes with large deviations from the original flight plan. Additionally, the computation of optimal routing through a 3D wind field is a complex problem with potentially unintuitive solutions, especially over long distances, and is well suited to automation. Thus, TAP is able to produce better solutions with far greater ease than could a pilot with the tools available on the typical flight deck today.
Subsequent efforts in the TASAR project focused on the inclusion of convective weather data (Section IV). Similar to wind, flights today are planned to route around the severe weather indicated by the best forecasts available in the hours prior to departure, a process which may be quite conservative given the uncertainty inherent in weather prediction. Additionally, other constraints imposed by the FAA, such as a National Severe Weather Playbook reroute, may further diminish the optimality of the pre-departure flight plan. The potential for TAP is then to improve upon the original flight plan while accounting for the most up-to-date convective weather data available.
The importance of this data follows from the core purpose of TASAR to provide useful reroute recommendations to the aircrew. Since the aircrew has the responsibility for avoiding severe weather during flight, TAP's solutions should have an awareness of the same convective weather as the aircrew have available in order to improve the acceptability of its solutions to the aircrew during operations impacted by weather. Otherwise, TAP reroute suggestions provided without knowledge of regions of convective weather could route the aircraft too close to weather hazards, limiting their acceptability to the aircrew in those situations.
C. Scope of Weather Functionality
In this discussion, it is important to underscore the intended use of TAP in general, as well as its weather functionality in particular. TAP is currently uncertified software (although it could potentially be certified by an avionics vendor in a commercial implementation) that is intended to provide advisory-only recommendations to the aircrew. However, these advisories must not be solely relied upon for safety-critical decision making without verification by other methods. With respect to weather, the intended use of TAP is not as a weather avoidance tool or display of weather data. The aircrew continues to use all standard procedures and equipment for navigation and weather avoidance, and any TAP advisories must be validated using normal practices prior to execution. In other words, the use of TAP does not change the responsibilities of the aircrew or convey any "operational credit."
The goal of the TASAR effort has been to explore and demonstrate the value of the concept through the development and evaluation of a software prototype and associated procedures, with a successful demonstration and transfer of technology to the aviation industry intended as the final product. However, as TASAR is a research project and TAP is prototype software, many of the technical decisions have been made based on the goals and constraints of the research environment. We expect further effort will be necessary by the private sector in order to fully commercialize the technology and realize broad benefits through implementation across the industry. Additionally, while NASA's focus in the development of TASAR has been on present-day airline operations, the concept and technology are no less applicable to other present and emerging classes of aviation vehicles and operations. This paper discusses several prototype weather processors that were developed to temporarily fill gaps in the products currently available from public and commercial sources. Section IV discusses a prototype processor for ground-based weather data, and Section V a prototype processor for airborne weather radar data. However, TAP is designed to be a consumer rather than a producer of winds and other weather data, and sophisticated weather processing is best left to an external service provider that specializes in that function. The prototypes described here are placeholders intended to enable the end-to-end demonstration of the TAP software and the TASAR concept, and to motivate the development of new weather products to meet the emerging needs of these operational technologies.
III.
Wind and Temperature Data TAP relies on atmospheric wind and temperature obtained from the Rapid Refresh product published by the National Oceanic and Atmospheric Administration (NOAA) on a publicly available website. The EDS downloads this data once per hour as new files become available.
In particular, TAP extracts the 3D gridded wind and temperature data from a file published under the label "awp236." This is an aviation weather product defined on a Lambert conformal conic projection covering the contiguous United States with a horizontal grid resolution of approximately 40 kilometers. Once downloaded, the EDS down-samples the data by interpolation to an equirectangular latitude/longitude grid with points equally emendoza@example.org° intervals in both directions. The resolution of this down-sampled grid varies between approximately 60 and 90 kilometers due to the construction of this projection. This down-sampling is performed for a several reasons, primarily for ease of implementation as well as performance optimization within the TAP Engine's trajectory generator. The wind vectors are interpolated on this grid whenever the wind is needed at a given position by TAP.
In the vertical dimension, the file provides data on a series of constant pressure levels defined between 1000 and 100 millibars in steps of 25 millibars, which roughly spans 400 feet to 52,000 feet above mean sea level under assumptions of a standard atmosphere model. TAP interpolates between these pressure levels when the wind at a given altitude is required by TAP.
At download time, TAP obtains the "zero-hour" forecast data representing the atmospheric prediction that corresponds to the nearest prior whole hour. TAP makes an assumption that the wind and temperature fields remain constant over time for any given trajectory prediction. Of interest in future work is to determine whether this constant wind grid assumption is sufficient for TAP's intended purpose, and what would be the incremental benefit of incorporating future forecast winds into the software.
Also of interest is the incorporation of higher resolution data such as the 3-kilometer High-Resolution Rapid Refresh model, as well as the expansion to a global wind grid. Similarly, a more sophisticated technique would blend the forecast wind grid with the sensed winds from the ownship and other aircraft.
IV. Ground-Based Weather Data
While wind and temperature are gridded products, the remainder of the discussion focuses on polygon-based weather products used by TAP. TAP's optimization algorithms are designed to generate route advisories that are free of conflicts with a variety of hazard areas described by four-dimensional (4D) polygons, including SUAs and convective weather. Each polygon is a prism described by a lateral shape that is extruded from the ground up to a given ceiling altitude. In addition to the 3D volume, the time of validity of each polygon is defined as an interval bounded by its activation and expiration times. A trajectory is considered to be in conflict with a polygon if the aircraft is predicted to be within the polygon volume at any point during its time of validity. TAP filters the candidate trajectories it generates to ensure that the reroute advisories shown to the aircrew are free of conflicts with the current set of 4D polygons.
A. Ground Data Server
While TAP downloads winds and temperature directly from the NOAA website via the airborne internet connection, it relies on the off-board processor known as the Ground Data Server (GDS) to provide 4D weather polygons generated based on other ground-based data sources. The GDS serves as a preprocessor of the data obtained from a weather service provider and provides it in a suitable format to the EDS running onboard the aircraft via the internet. The location of the GDS functionality on a ground-based server is intended to alleviate concerns regarding the bandwidth cost of the airborne internet connection as well as the limitations on processing power available on the EFB system where the TAP software is hosted.
The current implementation of the GDS used for NASA's internal testing as well as for the operational evaluation of TAP with Alaska Airlines is hosted on-site at Langley Research Center. It is comprised of two server components: i) a program that performs the downloading and processing of the data obtained from the weather data provider, and ii) a web server that makes the processed weather data available to clients via the internet. Clients such as the TAP EDS can access this server to obtain the latest set of 4D polygons published by the GDS. The data sources used by GDS and its process to produce polygons are described in the following sections.
B. Convective and Turbulence SIGMETs
Convective SIGMET (SIGnificant METeorological Information) advisories are issued in the U.S. by National Weather Service forecasters according to a variety of criteria, including the extent, duration, and severity of system of thunderstorms, as well as the presence of tornados, hail, wind gusts, wind shear, and convection-induced turbulence [14, 15] . In addition to the potential for turbulence associated with a convective SIGMET, turbulence SIGMETs may also be issued for areas of moderate or severe clear air turbulence over a significant geographical area. The guidelines for issuing SIGMETs that are followed by government forecasters are targeted to a broad range of aviation vehicles and operations, including general and business aviation. In addition to government-provided SIGMETs, commercial vendors serving airline customers typically employ staff meteorologists who provide a tailored set of SIGMETs that are most relevant to the airline's fleet and operations, which may involve a more appropriate set of weather criteria.
The SIGMET product used in the operational evaluation of TAP, obtained from a commercial weather service provider, is directly provided in the form of a 4D polygon (i.e., lateral shape, floor and ceiling, start and end time). Therefore, minimal preprocessing is required to make this data product available to TAP. The GDS checks for SIGMET updates every 5 minutes, at which time it makes the new set of SIGMETs available for download by the EDS.
The primary window of usefulness of a SIGMET is typically considered to be a window of several hours in advance of the aircraft's encounter with the geographic area covered by the SIGMET. Once the aircraft is airborne and within about an hour's flying time of the area in question, other sources of data such as weather radar may be more accurate and more suitable for weather avoidance decision making.
To reflect this preference within TAP, the activation time of each SIGMET polygon is modified by the GDS to ensure that it does not unduly restrict the TAP software's ability to find optimal trajectory solutions. This is currently accomplished by setting the SIGMET activation time to be no sooner than 70 minutes from the current time, reflecting the emphasis on SIGMET use for long-range planning rather than immediate weather avoidance. (SIGMETs with an original activation time greater than 70 minutes in the future are left unchanged.) TAP currently incorporates convective SIGMETs with severity of moderate or greater and turbulence SIGMETs of severe or greater. These initial thresholds were chosen based on feedback from NASA's airline partner and are adjustable via GDS configuration on the ground (but not by the pilot using TAP onboard).
C. Ground-Based Radar
Whereas SIGMETs are useful for long-range planning and typically cover relatively large geographic areas, they are less useful to the aircrew when making airborne route planning decisions within the next hour. Observations from ground-based weather radar provide a more accurate and up-to-date picture of the current convective weather across the country, compared to the blanket guidance generally provided by SIGMETs. Additionally, state-of-the-art numerical weather prediction can provide radar-like forecasts with a useful horizon for aviation trajectory planning of several hours into the future.
There is precedent for the use of 4D polygons to represent hazardous convective weather in an aviation context. For example, the Convective Weather Avoidance Model (CWAM) defines a probabilistic weather avoidance field built on numerical forecast predictions of vertically integrated liquid, which is a radar-derived estimate of the total mass of precipitation in a given column of air. Thus, CWAM represents regions of airspace that pilots are likely to avoid due to the presence of convective weather at a series of forecast intervals out to two hours from the present time [16] . In practice, the weather avoidance field is converted to a set of polygons similar to those employed by TAP.
While CWAM is an excellent product with which NASA has experience in the context of several research projects [17] [18] [19] [20] , it is not yet widely available to airline users (although it is a part of the FAA's impending rollout of the NextGen Weather Processor [21] ). For the operational evaluation with Alaska Airlines, it was important to identify a weather data source that would be compatible with the airline's current operational approvals and practices. In particular, this airline uses an FAA-approved Enhanced Weather Information System (EWINS) product from a commercial provider as the primary source of weather data for its operations. Thus, in order to demonstrate the adaptability of the TAP system to this product and comparable products used by other aircraft operators, this particular commercial service was chosen as the source of ground-based radar and SIGMETs for the current stage of this project.
Ground-Based Radar Data Products
The radar products used in the current evaluation of TAP are the base reflectivity and echo tops, which are common weather products available directly from the government or from third party vendors. Radar reflectivity measures the intensity of the radar echo reflected back from the weather target, which is usually precipitation. The echo tops indicate the altitude of the highest radar echo detected at any given position.
Reflectivity is measured in units of dBZ ("decibel relative to the reflectivity factor Z"), which is a logarithmic, dimensionless quantity, on a scale ranging from 5 dBZ (rain or mist that is hardly noticeable) to 65 dBZ (extreme rain and large hail). The radar reflectivity product is provided in a two-dimensional (2D) map of dBZ values representing the reflectivity at any given location on the plane of the radar scan. Reflectivity measurements from many stations are combined together in a mosaic to provide coverage across the entire country.
Base reflectivity refers to the elevation angle of the radar beam, indicating that it is a scan of the "base," or the lowest level, of the weather target [22] as depicted in Fig. 2a . In an aviation context, base reflectivity has limitations since it only directly measures the lower-altitude precipitation associated with a weather system, potentially misrepresenting the activity at higher altitudes that may be more relevant to a typical airline flight.
Contrast base reflectivity to the reflectivity obtained from a series of scans across a sweep of elevation angles, as depicted in Fig. 2b . Such scans can be combined into a single image representing the maximum intensity measured in a given vertical column, a product known as composite reflectivity [22] . Better yet, these scans can also be processed into a 3D model of the precipitation associated with the weather system, representing the structure of the system across a range of altitudes (known as the constant altitude plan position indicator), which would be ideal for TAP's 4D trajectory optimization purposes. Even though composite reflectivity imagery has benefits for use in aviation operations, base reflectivity imagery was chosen for this project since it was the best supported product by this particular vendor during the GDS development period. Additionally, as our experience has found it to be the most commonly available product from a variety of sources, there is a strong motivation for designing TAP to use a common denominator rather than tailoring it to something that is more difficult to obtain. However, the intent is that TAP evolve to incorporate better data at any given time as new products become available.
In order to construct a lateral polygon shape from this map, it is necessary to select a threshold to define which areas should be excluded from TAP's trajectory solutions. This threshold should roughly correspond to the kind of weather avoidance decisions that would be made by the aircrew when looking at the radar imagery. While there are many factors that go into such a decision-making process, a value of 40 dBZ, which represents moderate or moderateto-heavy rain, is typically used as a threshold to delineate convective activity that is hazardous to aviation at the altitudes relevant for TAP's operation [22] . This threshold was chosen as the basis for polygon generation in GDS.
The echo tops data, which is derived from radar reflectivity, is provided in a separate 2D map whose values represent the altitude of the highest radar echo measured by the radar station as it sweeps from base to maximum elevation. In other words, it is a measure of the maximum altitude of the observed precipitation at any given position.
TAP uses two sets of radar data: current and forecast. The current radar data represents the "nowcast" based on the reflectivity and echo tops data sensed by the Next-Generation Radar (NEXRAD) network operated by the National Weather Service. The forecast radar data are derived from the vendor's mesoscale numerical weather prediction model and thus represent a radar prediction rather than a radar measurement. GDS use both current and forecast radar products to produce set of 4D polygons that span from the current time to two hours into the future.
Radar Polygon Generation
Most weather radar products, including the data available from this particular vendor, are provided as color imagery meant for consumption by human eyes rather than by algorithms such as TAP's trajectory optimizer. Thus, the ground-based radar data polygons available from this provider require additional processing to convert them to a form suitable for use by TAP. Although the development of such weather processing technology is not a goal of the TASAR project, a prototype system was developed in the GDS as a placeholder in order to provide suitable weather polygons to facilitate the operational evaluation of TAP.
This GDS functionality is comprised of two programs: the Weather Data Requester (WDR) and the Weather Data Processor (WDP). First, the WDR downloads data from the weather provider via the internet. Figure 3 depicts a notional timeline showing when each weather data product is downloaded from its source by the GDS. The current radar products, as well as SIGMETs, are downloaded from the weather data provider every 5 minutes. The forecast weather data are downloaded every 15 minutes. These intervals correspond to the frequency at which the weather service provider makes new data available.
The previously discussed wind and temperature products downloaded by the EDS directly are also depicted in Fig. 3 For reflectivity, the download request directly specifies the 40 dBZ contour, as shown in dark blue in Fig. 4a . For echo tops, GDS requests the contours at flight level (FL) 250 through 500 in 5000 feet increments, an example of which is shown in dark yellow in Fig. 4b . The range of flight levels was chosen to span the relevant en route altitudes for TAP's operation on a typical airline flight. The interval of 5000 feet was chosen to minimize the number of polygons generated due to their impact on processing time in the TAP Engine as well as the potential for clutter on the TAP Display.
Once an entire data set of matched radar reflectivity and echo tops data is downloaded by the WDR, it provides that data set to the WDP for processing. First, the WDP filters out contours that do not meet a minimum size threshold based on the contour's area. Currently, the area threshold is set to 20 square kilometers. This step reduces processing time by filtering out small areas of convection that are not operationally relevant to TAP.
Next, the WDP simplifies the number of vertices in the radar contours in order to minimize processing time in the TAP Engine. The contours returned by the weather provider are in the form of high-resolution polygons carrying a greater level of detail than is necessary for TAP's use. Accordingly, the raw reflectivity and echo tops data are simplified in a process that generates a convex hull around each contour with a minimum number of vertices. Figures  4a and 4b show examples of these simplified convex hulls.
Using these simplified polygons, the GDS finds areas of intersection between each 40 dBZ reflectivity polygon and each of the echo top polygon sets, iterating in order from highest altitude (FL500) to lowest (FL250). This step is depicted in Fig. 4c , where the yellow represents the echo top polygons at FL300 and the blue represents the 40 dBZ radar reflectivity polygons. Wherever an intersection is found, the ceiling of the reflectivity polygon is taken to be the highest altitude of its intersecting echo top polygons. Reflectivity polygons that do not intersect an echo top polygon are discarded (i.e., they do not represent radar returns within the target range of FL250 to FL500). The floor of each polygon is set to the ground level, reflecting that TAP should not offer a trajectory advisory that passes beneath known convection, which is a reasonable assumption for en route airline operations.
Finally, lateral and vertical buffers are added to each of the remaining reflectivity polygons to create the final 3D polygon, as shown in Fig. 4d . Currently, GDS uses a lateral buffer of 5 nautical miles and a vertical buffer of 5000 feet, based on preliminary feedback from airline pilots. Note that the aircrew remains responsible for weather avoidance when considering the advisories offered by TAP, including the application of additional operationally appropriate buffers.
The output of this process is a set of 4D polygons whose time of validity spans the current time out to roughly 2 hours into the future. A timeline representing the set of current and forecast radar polygons, as well as the SIGMETs, is shown in Figure 5 . The set of current polygons is valid from the time of generation out to 15 minutes. Following that, a series of forecast polygon sets is valid for each subsequent 15-minute interval, ending with the 120-minute forecast polygon set. Finally, the set of SIGMETs is valid for the period of 70 minutes from processing time out to 135 minutes. This combined set of polygons is refreshed by GDS whenever new data becomes available as depicted in Figure 3 . 
V. Airborne Weather Radar Polygons
While the ground-based products provide a long range, strategic view of the weather, they do not always accurately reflect the situation in the immediate vicinity of a given aircraft. Ground-based radar products are generated from the data recorded by radar stations located on the ground, a process that has limitations due to the range and viewing angle of any given station's location. Accordingly, pilots are required to use certified onboard instruments such as airborne weather radar when operating in the vicinity of severe weather in order to provide a better picture of the nearby hazards.
Since airborne weather radar is an integral part of the aircrew's decision making process, the integration of airborne weather radar data into TAP was identified as an important research and design problem for TASAR. The working hypothesis of this investigation was that if airborne weather radar data could be integrated with the other ground-based weather products used by TAP, then TAP would be able to provide better trajectory optimization recommendations that are more acceptable and compatible with the aircrew's weather avoidance decision making, especially in the vicinity of convective weather activity.
Similar to the function of the GDS in processing the ground-based radar products, the Airborne Weather Radar Processor (AWRP) was designed to convert the raw data from an airborne weather radar system into a form suitable for use by TAP. There are a number of considerations in the design of such a processor, including the input data source, how that data is processed, the form of the output sent to TAP, and the software and hardware implementation of this process. What follows is a description of the AWRP prototype developed for internal research onboard a NASA aircraft; this functionality is not yet part of the operational evaluation with Alaska Airlines. Like the GDS weather processor, the AWRP prototype is a placeholder intended to facilitate the evaluation of TAP, which should be replaced with a more robust product in a future commercial implementation.
In order to leverage the existing functionality developed for the polygons used to represent SIGMETs and groundbased radar, the same polygon format was also chosen for the polygons to be generated by AWRP. With these design assumptions, AWRP's function is to continuously convert the raw radar image data received from the onboard radar into a set of 4D polygons and make them available to TAP via EDS in the same manner as the ground-based polygons available via GDS.
A. Airborne Weather Radar Data
A modern airborne volumetric scanning weather radar includes an avionics processor that constructs a sophisticated 3D representation of the weather target from the radar scans taken across many azimuth and elevation angles in rapid succession. Access to this 3D radar model would be desirable from the perspective of generating polygons for the purposes of TAP. However, this data is resident inside the radar processor and is not generally available to external consumers without a proprietary or vendor-specific interface. The processing required in a use of such data is also quite intensive and is beyond the scope of this project.
Alternatively, most radar systems output data via an ARINC 708 (sometimes referred to as ARINC 453) radar display bus, which drives the flight deck radar display used by the aircrew. This is a widely supported and welldocumented standard that can be used to access data from the radar system in a straightforward manner, although it carries its own limitations. Primarily, the data describes only the 2D radar image currently shown on the radar display, which corresponds to specific pilot-controlled settings, such as range, tilt, and gain. Thus, it represents a 2D slice rather than a 3D volumetric model of the weather target.
Because the data is limited by the pilot's current radar display settings, AWRP will re-compute its polygons whenever controls such as the antenna tilt angle are changed by the pilot, which may occur periodically during normal radar use. For this reason, there are no guarantees that the polygons generated by AWRP accurately reflect the weather that is relevant to the current route of flight at any moment. However, for the purposes of this project, the use of the radar display bus was chosen as the initial data source for AWRP based on ease of implementation and suitability for an initial proof-of-concept, relying on the NASA test pilots to appropriately configure the radar display to show the relevant weather for the current scenario.
The ARINC 708 format consists of a sequence of data frames, each frame representing the radar echo intensity along a given azimuth, typically ranging from about 60° left or right relative to the nose of the aircraft. Each frame provides the values of radar echo intensity along a series of points that are spaced between the nose of the aircraft and the current maximum range setting, which can range from 0.5 to 200 nautical miles or greater. The radar intensity at each point in the frame is given by a code that corresponds to the weather condition reported by the radar (e.g., light, moderate, or heavy precipitation).
The radar outputs a stream of frames tracking the changing azimuth angle as the radar antenna sweeps left and right in the horizontal direction. Each frame also includes other control information such as the current range and tilt angle setting. A standard radar display uses this angle-range information to build the 2D radar image shown to the pilot.
B. Data Processing
In the prototype implementation described here, the ARINC 708 data is obtained via a USB adapter connected between the radar display bus to a PC laptop running the AWRP software onboard the aircraft. Using this adapter, AWRP captures data frames at a rate of 120 frames per second, which is the native output rate of the radar system used onboard the NASA aircraft used for TASAR testing [11] .
After receiving the data, AWRP uses the azimuth and range information in each frame to project the radar intensity data onto a rectangular bitmap image. This represents the 2D radar image relative to the nose of the aircraft, as in a conventional airborne radar display.
Next, AWRP uses an image processing library to identify the regions of the image meeting a configurable threshold; in this case, the areas that would be displayed in yellow, red, and magenta on the flight deck radar display. This rule is used as a first-order approximation of the aircrew's weather avoidance decision-making process.
Then, the identified pixel areas are "inflated" by a number of pixels corresponding to a configurable lateral buffer. A lateral buffer of 5 nautical miles was chosen as an initial value representing the standoff distance from a significant radar echo employed in typical airline operations. In a commercial implementation, this value would be configured by the aircraft operator according to their company procedures for weather avoidance as well as FAA regulations. As is the case for the GDS polygons discussed previously, the polygons generated by AWRP are for advice only as a part of TAP's trajectory optimization process. The aircrew remains responsible for all weather avoidance decision making, including the application of suitable buffers.
Given the buffered pixel areas to be avoided, these areas are converted to a series of convex hull polygons in a similar manner to the GDS process. Subsequently, these polygons are converted from the aircraft-relative reference frame defined by the radar bitmap image to absolute coordinates using the current latitude, longitude, and heading of the ownship via a connection to the onboard avionics. These areas now define the lateral shape of the 4D polygons that AWRP will output to the TAP EDS. An example radar image and the resulting three polygons are shown in Fig. 6 .
Fig. 6 Airborne weather radar data and polygons generated by AWRP.
In the vertical dimension, the ARINC 708 standard does not provide any altitude information in the radar data stream. The data provided by the radar may represent weather above or below the aircraft, depending on the tilt angle and beam width of the radar scan, as well as a variety of automatic processing functions that are performed by modern radar systems. Rather than attempt to directly infer the altitude of the weather indicated by the airborne radar, the AWRP prototype instead relies on the principle that the pilot operating the radar will configure its settings to display whatever weather is most relevant in the current situation. That is to say, regardless of whether the radar returns represent convective weather below, at, or above the ownship's altitude, AWRP assumes the pilot has configured the radar to display what should be avoided with respect to the current route of flight or the proposed reroute. Accordingly, AWRP selects a ceiling for the airborne polygons based on the aircraft's current altitude plus a 5000 feet vertical buffer.
AWRP then sends the updated airborne polygon set to the EDS via a direct network connection at a configurable update interval. An interval of 10 seconds was used during the initial AWRP test flight, roughly corresponding to the time taken by this radar system to complete a horizontal scan.
In the long run, the kind of radar processing performed by AWRP onboard a single aircraft could be combined with the radar information from other aircraft in order to provide a better picture of the weather from multiple viewing angles. Additionally, the fusing of airborne and ground-based radar measurements and predictions could be combined to provide an even more comprehensive representation of the weather situation across the country. Ultimately, this function is an ideal candidate to be performed by a service provider that specializes in combining data from a variety of sources to produce a comprehensive set of polygons for consumption by tools such as TAP.
VI. Integration of Weather Data into the TAP HMI
The primary objective of the current series of investigations was the integration of airborne weather radar data with the other ground-based weather products used by TAP such that TAP would be able to provide better trajectory optimization recommendations that are more compatible with the aircrew's weather avoidance decision making process and more acceptable to the aircrew, especially in the vicinity of convective weather activity. Given that airborne weather radar is an integral part of the aircrew's decision making process when planning en route trajectory changes, it was equally important to investigate how best to display this weather data to the aircrew as well as determine associated functionality.
State-of-the-art weather information display applications typically present dozens of weather products overlaid on a map of the geographic region of interest. These applications provide a rich variety of near−real-time weather information that was unavailable to the aircrew prior to the widespread adoption of affordable EFB platforms and airborne internet access on the airline flight deck. However, the pilot is left to manage this potential deluge of weather data in order to retrieve the right information at the right time to make sound operational decisions.
A. TAP Weather Display Philosophy
Compared to a general weather display app, the graphical user interface design for the display and interaction with weather data on the TAP HMI presented a number of unique challenges. First, it is important to note that TAP's intended use is to provide route optimization advisories to the pilot and that the purpose of the display in general is to provide context for TAP's recommendations and enhance trust in the automation. However, it is not a certified display of weather data or a device, not intended to replace onboard weather radar or navigation devices, and is not to be used for making safety-critical weather avoidance decisions. Whatever trajectory optimizations are provided by TAP, the aircrew is still responsible for checking the reroute for all operational and safety of flight considerations using standard procedures and equipment before requesting approval from ATC. In the case of weather, this includes the use of onboard radar, visual separation from convective activity, and consultation with dispatchers and air traffic controllers. Accordingly, the initial functional prototype (see Fig. 7a ) of the TAP HMI did not present any information related to weather data, in any form (e.g., textually or graphically), to the aircrew.
However, the TAP HMI was developed iteratively using a human-centered design approach over a series of human-in-the-loop (HITL) simulation experiments and flight tests, and the design was continually expanded and refined based on knowledge gained during these activities [7] [8] [9] [10] [11] . Based on the results of subjective and objective data collected from evaluation pilots during HITL-1 and the first flight test (FT-1), human factors usability design principles, and tablet style guidelines (to accommodate the widespread use of tablet devices as EFBs), the TAP HMI was redesigned (see Fig. 7b ). The new design included a map display area to enhance situation awareness specific to TAP. This area included a graphical representation of the current planned route, the TAP-generated trajectory optimization, and simple polygons drawn to represent the approximate location of convective weather being considered by TAP. The weather polygons displayed on the HMI represent the areas used to filter candidate reroutes generated by TAP from presentation to the aircrew and thus help explain why TAP has suggested a given route when a more direct path may seem more obvious. However, the polygons do not indicate the high-resolution reflectivity intensity detail shown on a typical weather radar display. 
B. TAP Display Design Challenges
With the integration of additional types of weather data into TAP came the problem of determining how to display this information to the aircrew in an intuitive and usable manner. The fact that the polygons do not indicate the highresolution reflectivity intensity detail displayed on typical weather radar tools added to the design challenge. Because pilots are accustomed to using higher fidelity weather displays and interpreting characteristics such as color differences for levels of intensity, it was necessary to determine how to display similar weather with much lower fidelity while ensuring the information was also understandable and useful and did not impact pilot workload negatively. Additional HMI weather display design questions included the following:
 What type of weather data should be displayed to the pilots (e.g., current weather, forecast weather, onboard weather radar, SIGMETs).
 Fidelity of weather data (e.g., radar images, animation of polygons or radar images, entire radar map vs. TAP relevant portions only).
 How should the weather data be displayed? (e.g., appearance of polygon {color, fill, border, pattern}, grouping of polygons {i.e., should different types of weather be displayed as one polygon}).
 Controls -determine what controls allow intuitive interaction with the weather data (e.g., turning polygons types on/off at the display level only, affordance for turning weather data on/off at the TAP Engine level, controlling polygon buffer size).
C. Pilot Focus Group
In order to better understand how to design the display of the weather polygons, and as part of a technical risk reduction for the potential deployment of TAP's new weather functionality, a pilot focus group study was conducted to evaluate approaches for integrating airborne weather radar with ground based weather information. For this focus group, data were obtained primarily in the form of responses to a directed survey. Analysis of the survey responses and resulting recommendations for the integration of weather information into the TAP HMI are presented in this section.
While the ultimate goal of this investigation was to reduce the technical risk of enhancing TAP's utility and acceptability with hazardous weather information in its development of enhanced route solutions, specific goals of the focus group included: 1) provide insight into the potential functionality and utility associated with integrating onboard weather radar and data from ground-based weather products into the TAP software, i.e., how TAP should use data from these sources, and 2) provide insight into the HMI aspects of integrating new displays, symbology, controls, and capabilities to support the weather integration features of TAP.
Methodology Overview
Ten pilot subject matter experts participated in the three-part focus group which consisted of the administration of a questionnaire, a weather graphical exercise, and a group discussion. The questionnaire included questions regarding the pilot's familiarity with convective weather as it relates to aviation; on-board capabilities for obtaining weather information including capabilities such as weather radar, pilot reports of weather, and ground-based weather products available on the flight deck; the interpretation of weather information relative to areas that should be avoided due to severe weather; and severe weather avoidance techniques based on the interpreted weather information. After the completion of the questionnaire, a graphical exercise was conducted to complement the data obtained from the questionnaire relative to graphically depicted areas that in the pilot's judgement should be avoided due to severe weather. The third part of this focus group was a group activity where the pilots discussed the weather questionnaire and its components. The intent of this activity was to obtain further inputs and clarification related to the topics of the questionnaire, group consensus on specific weather questions, and to provide a forum to capture issues and insights to aviation weather topics that may not have been addressed in the questionnaire. Additionally, the pilots were presented with mock ups of display features and design options. Feedback from the pilots regarding these design options was recorded and compiled for use in future design updates.
Recommendations for Weather Integration into the TAP HMI
The following recommendations for integrating weather information into the TAP HMI are based primarily on the subjective responses from the weather questionnaire and from information obtained during the group discussions. Recommendations can be categorized into two topic areas: feature selection and display element presentation. These HMI recommendations are as follows:
Feature selection:
 Provide the pilot with the ability to display or hide polygons that represent convective weather, polygons representing turbulence, and wind direction.
 Provide the pilot with the ability to select from multiple, candidate reroute options based on the weather display options that have been selected.
 Provide the pilot with the option to visualize weather and turbulence at selectable altitudes.
Display element presentation:
 Display the order of the candidate reroute options such that the first displayed flight paths are those that are upwind of the weather.
 Display separate polygons for convective weather and turbulence weather, with the type of weather differentiated by the coloring of the polygons.
 Always draw only one polygon around clusters of severe convective weather if the distance between cells does not meet the minimum lateral and vertical separation distance as previously noted.
 Always draw polygons around green weather areas that contain yellow areas in a typical weather radar display.
As depicted in Fig. 8 , select pilot focus group recommendations were implemented into display design updates which were subsequently tested during flight tests prior to the operational evaluation flights. 
D. Flight Tests and Operational Evaluations
The TAP HMI with updated weather display design features was tested during flight tests in NASA aircraft as well as onboard Alaska Airlines aircraft as part of the TASAR Operational Evaluation. Subjective and objective data were collected from pilot SMEs and Alaska Airline pilots. Usability issues as well as operational functionality concerns were assessed during these flights and subsequent updates to the HMI were made.
Weather polygon fill color
As can be seen in Fig. 8 , based on pilot feedback during the pilot focus group, the color blue (to provide an immediate graphical differentiation between weather polygons and other types of polygons such as SUAs) was chosen to fill the weather polygons with a difference in the polygon border to indicate different sources of weather data (solid border for current weather, dashed border for forecast weather). However when this was presented to the pilots at Alaska Airlines they indicated that the polygons looked exactly like lakes in one of their pilot apps and would be a potential source of confusion for the pilots. This issue is related to the previously stated display design challenge of fidelity. A basic human factors design principle is to maintain consistency with what end users are familiar with (i.e., although different types of computer keyboards are available, the familiar QWERTY layout is always preserved). Because we were unable to display weather data with higher fidelity (including high-resolution reflectivity intensity detail), it was difficult to determine how best to display basic two dimensional polygons such that pilots would be able to easily identify them and differentiate between different types of weather data. Obviously, having the blue filled polygons interpreted incorrectly as lakes on the display was not desirable or operationally functional. Subsequently, the fill for the weather polygons was changed to a pattern fill (see Fig. 9 ).
Time slider functionality
With the integration of time-dependent weather data (e.g., current, forecast) into TAP came the challenge of determining how to display 4D information to the pilots on a 2D display. Higher fidelity weather displays accomplish this by providing the animation loop to depict the weather as it moves and changes across time. This feature allows the user to intuitively understand the dimension of time. The fundamental human factors challenge was to overcome how the user perceives the polygons on the display, even if the polygons representing different weather types (specifically current and forecast weather) are drawn differently. When current and forecast polygons appear on the display at the same time next to the route information, the user is likely to immediately perceive them all as "now." So if a TAP-generated trajectory is drawn through a forecast weather polygon without indicating a conflict, it can be confusing to the user because it is not intuitive that the polygon is representing weather that will not be relevant to the aircraft when it arrives at that point on the trajectory.
During the iterative design process several display design options were developed to mitigate this challenge. Examples include drawing the polygons with basic white borders and relying on the data tag to differentiate between types of weather data, using a different fill color for each type of weather data, and using the same polygon fill color but drawing the borders of the polygons differently. However, these options were not sufficient for several reasons. For example, as the number of different types of weather data included on the display grew it became clear that creating different polygon fill colors would negatively impact pilot workload simply trying to remember which color represented which type of polygon. Drawing the borders differently was problematic because often the polygons on the display appear very small in which case the user cannot see the borders well enough to differentiate between them.
A reasonable solution was developed by developing a functional "time slider" tool that allowed the pilot to select increments of time to be displayed as opposed to displaying all of the weather polygons simultaneously. Using the time slider tool, the pilot can select different advances in time to view the respective weather polygons on the display, with a circular icon appearing on the trajectory corresponding to approximately where the aircraft would be at that time. Fig. 9a illustrates the time slider (square icon in bottom right of display) with the current time selected, and Fig.  9b with one hour in the future selected. Notice the circular aircraft icon on the trajectory appears in the one hour forecast, and the avoidance polygons change location and size based on that particular forecast. 
VII. Alternative Approach to Weather Constraints
The 4D polygon approach in TAP used to represent SUA and convective weather hazards is designed to be adaptable to other kinds of constraints that are relevant to TAP's optimization objectives. The polygons are currently treated as a "hard" constraint, in that TAP rejects any candidate trajectory that intersects with any polygon in a 4D sense (i.e., the aircraft is predicted to pass through the polygon during its time of validity). This works for well-defined areas of severe convective weather or airspace constraints where entry is prohibited or avoided whenever possible.
Such polygons could also represent a variety of "soft" constraints. For example, turbulence is a significant factor in aviation flight planning, and safety and ride comfort rank highly among the priorities of the major airlines. However, it is difficult to define hard boundaries for turbulence areas, which may be geographically widespread, intermittent, and difficult to detect. However, rather than treating it as a hard constraint, as in the case of the severe turbulence SIGMETs currently used by TAP, such a turbulence area could instead be treated by TAP as a "soft" constraint by providing trajectory solutions that minimize the intensity-integrated exposure time spent flying in those areas. Thus TAP's solutions might be biased away from areas of known turbulence, but not avoided completely, which represents the tradeoffs used in routine flight planning. The weighting factor between time and fuel vs. turbulence exposure could be selectable based on pilot or company preferences.
VIII. Conclusion
Weather is a significant part of the planning process of any given flight, and it is also relevant to the in-flight reroutes that TAP is designed to generate. The efforts to integrate a variety of weather data into TAP have enabled the end-to-end, proof-of-concept demonstration of the TASAR concept in simulation and flight activities. While the promise of this overall philosophy and approach to TASAR weather has been demonstrated, significant work remains to realize its full potential. In particular, the weather processors discussed in this paper were developed as placeholders to facilitate the TASAR evaluations, and were not intended for regular operational use. Whereas there are a wide variety of aviation weather products intended for human consumption, there exists a gap in the readiness of these corresponding products for automated use by tools such as TAP. Thus, there is a great opportunity for commercial vendors to provide these services in the future.
Within TAP itself, there are a number of open questions related to how the weather data is used by optimization algorithms as well as how the data is presented to its pilot users. For the purposes of this project, TAP was designed as an uncertified EFB application. In the present implementation, there are deliberate choices in the TAP design to ensure its functionality and intended use do not raise to a level that would require a certification process that would be prohibitive to TASAR research project or early adopters. However, in a commercial implementation of TAP, there is the potential to more closely integrate the TAP functionality with a wide variety of other weather data and flight planning applications used by the aircrew during normal operations.
Given the emerging trend of cockpit connectivity and the growing number of data sources that are becoming available on the flight deck, the aircrew is faced with the classic problem of "information overload." What is needed is not more data all the time, overlaid in an endless series of layers on a map display, nor knowing with extreme accuracy where the weather is and what it's doing. Rather, the job of the pilot is to fly the airplane, and to make decisions regarding the best trajectory for that airplane given the best knowledge available in flight. TASAR takes the first steps in this direction, and this research domain is ripe for further innovation.

{'paper_id': '196185105', 'title': 'Weather Design Considerations for the TASAR Traffic Aware Planner', 's2_url': 'https://api.semanticscholar.org/CorpusID:196185105', 'source': 'S2ORC'}