Weather Information and Toolset Content Decision

Design Decisions

Device Support

• Support iPad and Android tablets via cross-platform framework:** Must support iPad, because they are the dominant platform among current/emerging aviation users.** Should support Android, because there is a large potential user base and the trade-off of using a cross-platform framework is minor.
• Do not support phones as a primary platform, because they are a sub-optimal platform that should be replaced by larger format devices. However, allow display of content on these devices where possible, and support phone access of content that is of high-priority to user groups indicate a preference for phone viewing.
• Support desktop browsers, if possible without significant effort above that of supporting tablets. 

Network

• Implement assuming internet access, since this is the preferred technological solution.
• Document the current gap as part of the MobileMet documentation
• Do not support:** XM, because adds too much effort and may not be a long-term solution** ADS-B, because does not support request/response, even though it is a funded FAA capability that will be available for free
• Priority of access: phase of flight (pre-flight, pre-launch, in-flight), users (GA, 135, 121), data (all, ADS-B FIS, or XM)
• Device Agnostic and automatic switching: WIFI, 4G, ADS-B?, XM?, off-line

Information Content and System Capabilites -- Selection Methodology

In order to determine the most important elements to include in the proposed mobile display, two analysts (Barron, Dumont) designed grids to consolidate data from user interviews, simplifying comparison of this complex data. One grid represents information content (weather, aeronautical, and astronomical information). The other represents capabilities to be provided by the proposed system (features, processing,  and user interface). Rows in each grid represent user groups and phase of flight. Columns represent categories of content or capability, for which priorities were being established. The analysts independently filled in the grids and compared their results. Any values that diverged significantly between the analysts were discussed in order to come to a consensus value. This process helped clarify each analyst's interpretation of the categories and what was presented in the user interviews. Columns were then averaged in the consensus grid and sorted based on the average priority for all user groups and flight phases. The resulting grids are shown in Figures 1 and 2.

In order to reduce the scope of the current year's effort and to minimize the effects of averaging user groups and flight phases with dissimilar needs, the analysts then looked for patterns in priorities between these groups and phases (rows in the grid). The hope was to find a set of capabilities and information that could be supported in the first year of development that might support as many users as possible, in as many phases of flight as possible. The hope was also to create a prototype that could be tailored to different pilots' needs, and easy to integrate into their workflows. In this way, the development team hopes to maximize the utility of the prototype application to support various user evaluations, something hard to do with a catch-all tool designed to support a diverse user base. The first consequence of this analysis was to remove the ground-based operations from the analysis and re-sort the results. Ground-based users have divergent needs from pilots, such as a focus on desktop-viewable application, which are of little use to pilots en route. Because the focus of the project is to evaluate the potential benefits of mobile devices in the cockpit, and the needs of ground-based users were so divergent, it was decided to exclude them from prioritization. Analysts further reduced the number of user groups and flight phases, averaging just GA and HEMS pilots for all phases of flight, only HEMS pilots, only GA pilots, and finally removing the flight planning phase from each of these groupings. The analysts then compared the results to see whether eliminating different user groups of flight phases resulted in different priorities. The sorted results were broken into three groups of priority -- essential, desirable, and optional -- by identifying breaks in the averaged priority values. In cases where obvious breaks were not present, the groupings were chosen by changes in slope of the priority curve. Results are discussed below.

Figure 1: Importance of "System Capability" categories to all Users at all Flight Phases, sorted by average priority
Priorities have the following meanings: 5. Essential (Can’t fly without it); 4. Very Important (Need it); 3. Desirable (Want it); 2. Optional (Could do Without); 1. Useless (Very Low Value)

Figure 2: Importance of "Information Content" categories (weather, aeronautical, and astronomical information) to all Users at all Flight Phases, sorted by average priority.
Priorities have the following meanings: 5. Essential (Can’t fly without it); 4. Very Important (Need it); 3. Desirable (Want it); 2. Optional (Could do Without); 1. Useless (Very Low Value)

System Capabilities

( Click here for more information on System Capabilities - Detailed Category Descriptions )

Initial inspection of user priorities for system capability identified that the flight planning phase had divergent needs from other flight phases, such as a strong disinterest in moving-map display, tablet-viewable information, and other features important to pilots who have begun their flight. For this reason the flight planning phase was removed when establishing priorities for system capabilities. It seemed prudent to decide that the first year of effort will be directed towards developing an evaluation application for pilots who have completed their planning phase of flight, even though the application may contain many or all of the data sources desired for that phase.

Analysts compared three groupings of users in order to establish priorities for system capability, considering only the preflight, en route, and intermediate stop flight phases: 1) All pilots, 2) GA and HEMS pilots, and 3) HEMS pilots. The resulting 3 priority sets had excellent correlation for all groupings. Relative rankings of some capabilities were different between user groups, but these did not affect the placement of categories in the overall priority groups. See Figures 3 and 4.

Essential
Current Time Selection
Destination Airport
Alternate Airport(s)
Data Comm Status
Plan View
Future Time Selection
Origin Airport
Tablet-Screen Viewable
Text (decoded?)
Moving Map with Current Location
Fast Glance

Desirable
Time Aggregation (animation)
Phone-Screen Viewable
Along Route (very important to x-country GA pilots)
Nearest Airport(s)
Ship Location
Graphical Trending
Scripted Scenarios
Next Airport
Limited Detail with Drill-Down

Optional
Reporting Weather/Location
Past Time Selection
Alerts
Flexible Layout
3D View
Comprehensive Info Access
Desktop-Screen Viewable

Figure 3: System capabilities sorted by average priority for all pilots, with the flight planning phase removed.

Figure 4: System capabilities sorted by average priority for GA and HEMS pilots, with the flight planning phase removed. Handwritten numbers at top indicate priority group ranking for all pilots view.

Information Content

( Click here for more information on Information Content - Detailed Category Descriptions )

User priorities for information content diverged less for the planning phase of flight than system capabilities did, but for consistency the analysts looked at only the post-planning phases: preflight, enroute, and intermediate stop. In this case, it was important to look at three groups of users: 1) All pilots, 2) GA and HEMS pilots, and 3) HEMS pilots in isolation. Overall, there was excellent correlation between the user groups, with the exception of a few categories that HEMS pilots prioritized differently. In these cases, HEMS pilots either felt that the information was essential when other pilots did not or felt that the information was optional when other pilots did not. Those differences are noted in the list below. See Figures 5, 6, and 7 to reference the sorted tables.

Essential
Ceiling
Visibility
Airport Location
Winds
Storms (turb, front, ice)
NOTAMs (Optional for HEMS pilots)
Icing
Precip Type

Desirable
Radar
Precip Rate
Runway Conditions (Optional for HEMS pilots)
Aviation Obstructions (Essential for HEMS pilots)
Cities and Towns (Essential for HEMS pilots)
Navigation Fixes/Routes
Lightning
Terrain
Weather Cameras
Airport Layout (Optional for HEMS pilots)
Turbulence
Dew Point
Sunrise/Sunset/Moon (Essential for HEMS pilots)
Temperature
Highways/Roads/Streets (Essential for HEMS pilots)

Optional
Satellite
Lakes and Rivers
Airport Services
Moonrise/Moonset (Essential for HEMS pilots)
NWS Text Area Forecasts
Counties
NWS Text Forecast Discussions

Figure 5: Information content categories sorted by average priority for all pilots, with the flight planning phase removed.

Figure 6: Information content categories sorted by average priority for GA and HEMS pilots, with the flight planning phase removed.

Figure 7: Information content categories sorted by average priority for only HEMS pilots, with the flight planning phase removed.

Architecture

• Server-side:
  • data ingest/processing
  • data services
• Data Com:
  • Grids: WMS (tiled?), NetCDF, or GIF/PNG?
  • Features: WFS (GML or JSON), JSON, XML, NetCDF, or binary?
  • Other: JSON, GML/XML, NetCDF, or binary?
• Client-side:
  • 3rd-party dependencies:
    • mapping: OpenLayers, GMaps, Yahoo, or other?
    • graphics: Native, JQuery Mobile, Sencha, or other?
    • com: JQuery, PhoneGap, other?
    • security: ?
• Development/deployment: software and hardware
• Documentation: client
•