7.6 Data Tag Decluttering. The traffic display should provide the capability to hide/redisplay optional elements of the data tags as part of decluttering.
7.7 Data Block Location. If a data block is used to provide additional information about selected traffic, it should appear in a consistent location that does not hide information essential to flight crew tasks.
7.8 Data Tag Positioning. The positioning of data tags should be consistent with the positioning of traffic altitude.
8. Traffic Altitude and Vertical Speed. Altitude and vertical speed is displayed in a traffic symbol’s data tag for airborne traffic. “Relative Altitude” is the altitude difference between traffic and own-ship. “Actual Altitude” is the pressure altitude of traffic above mean sea level.
The display of geometric altitude is not addressed in this AC. See also this Appendix, Section 7, “Traffic Data Fields.”
8.1 Format of Relative Altitude Data. Relative altitude should be displayed as a 2-digit number representing hundreds-of-feet altitude difference from own-ship. For example, “+70” would represent 7,000 ft above own-ship. The relative altitude value of traffic aircraft located above the own-ship should be preceded by a “+” sign and displayed above the traffic symbol.
Conversely, the relative altitude value of aircraft located below the own-ship should be preceded by a “-” sign and displayed below the traffic symbol.
8.2 Format of Co-Altitude Relative Altitude Data. The relative altitude for traffic that is located at the same altitude as the own-ship should be displayed as the digits “00”, and positioned above the traffic symbol if the traffic closed from above, and below the traffic symbol if the traffic closed from below. If no trend information is available, the co-altitude “00” symbol should be placed below the traffic symbol. To prevent distractions to pilots, co-altitude data tag information should not unnecessarily toggle between the positions above and below the traffic symbol.
8.3 Selection of Actual Altitude Mode. The traffic display should provide the pilot with the option to select the display of traffic’s actual barometric altitude in place of relative altitude.
8.4 Indication of Actual Altitude Mode. An explicit indication (e.g., text message) should be provided on the traffic display when the Actual Altitude mode is active.
8.5 Consistency of Altitude Type. Altitudes for all simultaneously displayed traffic should be of the same type: "relative" or "actual.”
8.6 Format of Actual Altitude Data. Actual altitude, if shown, should be displayed as a 3-digit number representing hundreds of feet above MSL. For example, “070” would represent 7,000 ft MSL. Negative flight levels (i.e., below MSL) should be preceded by a minus sign. The altitude should be positioned above or below the traffic symbol in a manner consistent with relative altitude data.
8.7 Corrected Actual Altitude. The display of actual barometric altitude while own-ship is below the transition altitude (18,000 feet MSL in the U.S.) requires a barometric pressure correction from own-ship. If barometric pressure corrections are not incorporated, the display of actual barometric altitudes below the transition altitude is considered potentially ambiguous, and APPENDIX H Page H- 7
may be displayed by pilot selection only for approximately 15 seconds per selection. See AC 20- 131A.
8.8 Indication of Traffic Vertical Speed. A vertical arrow, pointing up for climbing traffic and down for descending traffic, should be located immediately to the right of a traffic symbol if the traffic is climbing or descending at more than 500 feet per minute (fpm) relative to ground, and if traffic is reporting altitude. The color of the arrow should be the same as the traffic symbol color.
NOTE: The threshold value of 500 fpm is adopted from TCAS standards. Actual TCAS systems display vertical speed based on criteria that approximates 500 fpm. The use of TCAS criteria or similar criteria for the approximation of the 500 fpm threshold may be allowable.
8.9 Consistency of Traffic Vertical Speed Indicators. The criteria for displaying the traffic vertical speed arrow should be consistent across all displayed traffic.
8.10 Altitude Filter. A means should be provided to filter airborne traffic based upon their altitude.
8.11 Indication of Altitude Filter Setting. The altitude filter setting should be continuously displayed.
8.12 Altitude Filtering of Airborne Traffic While Own-ship is On Surface. A means should be available to optionally remove airborne traffic (e.g., above 1000 feet AGL) when own-ship is on the surface. See also Section 14, “Surface Traffic.”
9. Alerting Traffic. Traffic alerts can be visual or aural. The guidance in this section is a supplement to general alerting guidance (i.e., guidance not specific to traffic surveillance, as in AC 25-11 and SAE ARP4102/4), as well as to technology-specific alerting guidance (e.g., as in Appendix G, “TCAS and ASA Integration”). The guidance in this section does not supersede system-specific guidance (e.g., AC 20-131A, TSO C-119b).
9.1 Traffic Alert Integration. Traffic alerts should be integrated with other flight deck systems, follow a prioritization scheme, and be consistent with the flight deck alerting philosophy.
9.2 Alert Attributes. Traffic that triggers an alert should be indicated on the traffic display with information encoding that attracts attention, and is clear and unambiguous to the flight crew.
9.3 Attention-Getting. Attention-getting attributes of traffic alerts should not be distracting to pilots. Special consideration should be given to integration of attention-getting features with other displays in the flight deck. For example, short-term flashing symbols (approximately for 10 seconds, or until acknowledged) should be used only sparingly, and a permanent or long-term flashing symbol that is noncancellable should not be used.
9.4 Indication of Pilot Response. Traffic alerts should indicate whether or not an immediate response is necessary by the pilot.
9.5 Traffic Alert Colors. Traffic alerts must conform to the following color convention for visual alert indications (see 14 CFR §2X.1322):
• Red, for warnings.
• Amber/yellow, for cautions.
Page H - 8 APPENDI X H
The colors red and amber/yellow are normally reserved for alerting functions. The use of these colors for functions other than crew alerting should be limited and should not adversely affect crew alerting.
9.6 False and Nuisance Alerts. The traffic alerting system should be designed to minimize false and nuisance alerts while providing reliable alerts to the flight crew when needed.
NOTE: Research suggests that trust and reliance can be improved in some situations (e.g., low workload) by displaying data underlying the alert logic, or by incorporating multiple levels of alerts. However, such additional information might contribute to clutter and adversely affect workload. See also SAE ARP4153 for additional guidance on false and nuisance alerts.
9.7 Traffic Alert Inhibits. The presentation of traffic alert indications should be inhibited under certain conditions, such as where:
• The traffic alert could cause a hazard if the flight crew was distracted by or responded to the alert.
• The traffic alert provides unnecessary information or awareness.
NOTE: Alert inhibits are used to prevent the presentation of an alert which is inappropriate or unnecessary for the particular phase of operation. Alerts may be inhibited automatically by the alerting system, or manually by the flight crew.
9.8 Indication of Inhibited Alerts. There should be a clear indication that a traffic alert has been manually inhibited by the flight crew, for as long as the inhibit exists.
9.9 Aural Alerts and Pilot Communication. Presentation of traffic aural alerts should not inhibit pilot communication or other activities required to address the alert situation.
9.10 Displaying Alerts for Hidden Traffic. Symbology and required data tag information associated with alerting traffic should not be hidden by decluttering or filtering operations.
NOTE: Exceptions may be allowed for advisory-level alerts, or to accommodate alert prioritization schemes of other systems (e.g., terrain alerts). It might be appropriate to redisplay non-alerting traffic in order to facilitate visual acquisition of the intended target by the flight crew.
9.11 Off-Scale Alerting Traffic. Alerting traffic that lies outside the configured traffic display range should be positioned at the measured relative bearing, and at the configured display maximum range (i.e., edge of display), and with a symbol shape modification that indicates that the traffic is off-scale.
NOTE: A half-symbol at the display edge is one acceptable indication method.
10. Selected Traffic. In this Appendix, traffic that is selected by the flight crew is assumed to be only for the display of additional information beyond what is presented in the minimum data tag (see Section 7, “Traffic Data Fields”). The additional information might be customized for data block display, or for individual data tag display. This Appendix does not address the selection of traffic for advanced applications such as those involving coordinated maneuvers and passing maneuvers.
APPENDIX H Page H- 9
10.1 Selection of Any Traffic. If a means is provided for traffic selection, pilots should be able to select any target on the traffic display to obtain additional information.
10.2 Discernability. Selected traffic should be easily discernable from non-selected traffic.
10.3 Ease of Traffic Selection. The traffic display should allow the selection of traffic to be performed easily and rapidly.
10.4 Off-Scale Selected Traffic. Traffic that has been selected and then moves outside the configured display range should be positioned at the appropriate relative bearing, and at the configured display maximum range (i.e., edge of display), and with a symbol shape modification that indicates off-scale.
NOTE: A half-symbol at the display edge is one acceptable indication method.
11. Traffic Velocity Vector and Ground Track History. In this Appendix, traffic “velocity vectors” indicate the current horizontal velocity (magnitude and direction) with respect to the ground, and traffic “ground track histories” indicate past horizontal position with respect to the ground. The length of velocity vectors can be used to depict a horizontal position estimate of non-maneuvering traffic, for a given future time value. Traffic horizontal velocities that are not relative to the ground (e.g., traffic closure rate to own-ship) are not addressed in this AC.
“Directionality lines,” which depict velocity direction but not magnitude (i.e., length does not vary with traffic speed), and “position trend indicators” (i.e., “noodles”), which depict short-term trajectories for maneuvering aircraft, are not addressed in this AC.
11.1 Discernability. If velocity vectors and ground track histories are available for display, they should be easily discernable from each other, and discernable from related graphics such as vertical speed indicators, directionality lines, and position trend indicators.
11.2 Confusion with Vertical Speed Indicator. Velocity vectors should be depicted without an arrowhead to avoid confusion with the vertical speed indicator in the traffic symbol data tag.
11.3 Ease of Decluttering. Simple methods (e.g., single button push) for removing velocity vectors and ground track histories should be provided.
NOTE: Automatic decluttering of velocity vectors and ground track histories, such as during traffic alerts, may also be appropriate.
11.4 Interference with Other Traffic Information. Velocity vectors and ground track histories should not interfere with the legibility of other traffic information (e.g., data tags).
11.5 Selectable Time Value of Velocity Vectors. The time value associated with the length of velocity vectors should be selectable by the pilot.
NOTE: Changing the time value will also change the vector length, for a fixed display range.
The length of velocity vectors vary to reflect traffic speed, and hence future estimated position for a given time value. Therefore, small range values (zoomed in) can result in excessively long vectors, while large range values (zoomed out) can result in excessively short vectors.
Page H - 10 APPENDI X H
11.6 Automatic Changes to Time Value of Velocity Vectors. The time value associated with the length of velocity vectors should not change automatically as the traffic display range changes.
11.7 Indication of Velocity Vector Time Value. The time value associated with the length of velocity vectors should be continuously indicated when velocity vectors are displayed.
12. Display Zooming, Panning, and Orientating. Traffic displays typically need to spatially configured to be appropriate for the traffic application and the pilot’s immediate task. “Zooming” refers to changing the scale of the display field-of-view. “Panning” refers to the horizontal translation of the display field-of-view. “Orientating” refers to changing the orientation mode of the display; not the actual angular position. For Track-up or Heading-up modes, the angular position (with respect to the pilot) of the traffic display varies dynamically, based on own-ship state. For North-up mode, the angular position of the display is static. For related guidance on electronic maps, see RTCA/DO-257A.
12.1 Manual Zooming. The traffic display should provide the capability for manual zooming.
12.2 Minimum and Maximum Zoom. The traffic display range (zoom) should be adjustable to values suitable for the intended function of the traffic surveillance application.
NOTE: The choice of minimum and maximum range might include considerations of legibility and clutter. The choice of minimum range (i.e., zoomed in) might also include considerations of traffic and own-ship representation (e.g., symbol position, shape, and size) in order to minimize the risk of presenting misleading traffic position information. See also this Appendix, Paragraph
5.5, “Representation of Traffic Location.”
12.3 Indication of Display Range Value. The current traffic display range value should be continuously indicated, including the numerical value and its units (e.g., “10 nm”).
NOTE: When multiple range values are displayed (e.g., for each range ring), the units may be displayed only once.
12.4 Range Value Association with Display Elements. The current traffic display range value should be clearly associated with a graphical element dimension (e.g., range ring radius) or other display dimension.
12.5 Range Marking Discernability. The range markings should be easily discernable from other symbology used on the traffic display.
12.6 Default Range Setting. The traffic display should provide a simple means to revert to a saved or default range setting.
12.7 Orientation Mode. The traffic display should provide the capability for Track-up or Heading-up orientation mode.
NOTE: North-up mode might be needed to display some traffic during a loss of own-ship directionality (See this Appendix, Paragraph 4.7, “Loss of Own-ship Directionality”).
12.8 Indication of Display Orientation. The current traffic display orientation mode should be continuously indicated.
APPENDIX H Page H- 11
12.9 Indication of Automatic Display Orientation Mode Change. Automatic changes to the traffic display orientation mode should be clearly annunciated.
NOTE: The annunciation may be temporary and/or cancelable by the pilot.
12.10 Display Configuration Consistency. All data simultaneously presented on a traffic display should be based upon the same display configuration (zoom level, pan position, orientation). See also Section 15, “Multifunction Display Integration.”
12.11 Simultaneous Display Orientation Modes. Multiple traffic display orientation modes should not be displayed simultaneously. For example, a small “thumbnail” display that is presented simultaneously with the normal traffic display should each be oriented the same.
12.12 Maintaining Traffic Identity. Changes to traffic position and orientation due to display zooming, panning, and orientating should not cause the pilot to lose track of traffic identity.
12.13 Display Responsiveness. The display response time to display zooming, panning, and orientating inputs should not adversely impact workload or compromise the intended function of the traffic display.
12.14 Off-Scale Own-ship Symbol. If the traffic display can be panned/zoomed such that ownship is no longer in view, the display should indicate the own-ship position relative to the current field-of-view, and should provide an easy means to return to the default view.
13. Databases. In addition to an external data source, the own-ship traffic surveillance system might use an internal database to provide information that changes less frequently than traffic information, such as airport surface maps and TIS-B service areas.
13.1 Database Validity. Databases should be validated and updated according to existing guidance, such as described in RTCA/DO-257A, RTCA/DO-200A, RTCA/DO-201A, RTCA/DO-272, RTCA/DO-276, and their data should be displayed consistently with existing paper symbol equivalents and established industry standards, such as described in SAE ARP5289.
13.2 Simultaneous Display of Traffic and Database Information. Database-generated chart information that is presented simultaneously with traffic should not adversely impact pilot workload, compromise the intended function of the traffic display, or confuse the pilot by providing misleading information about the actual location of traffic.
NOTE: See also this Appendix, Paragraph 14.4, “Traffic Symbol Positions Over Airport Maps.”
14. Surface Traffic. “Surface Traffic” is defined here as aircraft and other vehicles such as service trucks. These are sometimes referred to in other documents as “A/Vs.” See also this Appendix, Section 8, “Databases,” as well as RTCA/DO-257A, RTCA/DO-289, and SAE ARP5898.
14.1 Indication of Traffic Air/Ground Status. The traffic display should be capable of indicating the air/ground status of traffic.
Page H - 12 APPENDI X H
14.2 Discerning Airborne Traffic from Surface Traffic. Airborne traffic, surface aircraft traffic, and other surface traffic (i.e., ground vehicles) should be easily discernable from each other.
NOTE: It may be appropriate to inhibit the display of altitude and vertical speed information in the data tag when traffic is on the surface. Changes to data tag information might not be a sufficient means for easily discerning surface from airborne traffic. The need to discriminate among surface traffic (e.g., aircraft versus trucks) might depend on the specific application.
14.3 Surface Traffic Alerts. Alerts associated with surface traffic should not interfere with the efficacy of alerts that are associated with airborne traffic.
NOTE: Alerts on individual surface targets might be avoided or complemented through other forms of alerting (e.g., runway-occupancy alerts). See also SAE ARP5898.
14.4 Traffic Symbol Positions Over Airport Maps. Traffic symbology and horizontal position accuracy should be sufficient to place the symbols within runway and taxiway widths.
NOTE: For some applications, traffic symbol shapes and positions might be used by pilots to determine runway occupancy. See also this Appendix, Paragraph 5.5, “Representation of Traffic Location.”
14.5 Display of Surface Traffic while Own-ship is Airborne. Surface traffic should not be displayed while the own-ship is airborne, unless appropriate for its intended function (e.g., display surface traffic only for a selected arrival airport).
NOTE: Automatic decluttering of surface traffic might be appropriate due to the high density of surface traffic, particularly when own-ship is airborne and the display range is configured for airborne traffic.
14.6 Ease of Switching Between Airborne and Surface Display Modes. If both airborne and surface applications are simultaneously available, there should be an easily selectable (e.g., one button push) capability to switch between each display mode.
14.7 Display Orientation When on the Airport Surface. Track-up or Heading-up orientation should be available for airport surface operations, each with a 360-degree view (see also this Appendix, Paragraph 12.7, “Orientation Mode.” In addition, North-up might be appropriate during a loss of own-ship directionality (see also this Appendix, Paragraph 4.7, “Loss of Ownship Directionality”).
NOTE: If own-ship uses ground track as the sole means of determining its directionality, this might cause own-ship directionality, and hence Track-up display orientation, to be frequently invalid.
14.8 Ease of Decluttering Airport Maps. If an airport map is displayed simultaneously with traffic, there should be an easily selectable (e.g., one button push) capability to declutter airport map information. See also RTCA/DO-257A.
14.9 Ease of Decluttering Surface Traffic. There should be an easily selectable (e.g., one button push) capability to declutter surface traffic information.
APPENDIX H Page H- 13
14.10 Data Tag Obstruction of Runway Labels. Data tags associated with surface traffic should minimize obstruction of runway and taxiway labels.
15. Multifunction Display Integration. A multifunction display (MFD) uses the same display hardware to present multiple applications/functions (e.g., traffic, weather, terrain).
15.1 MFD Display Configuration Consistency. Traffic and other information simultaneously presented on the MFD should be based upon the same display spatial configuration (e.g., range and orientation). See also Section 12, “Display Zooming, Panning, and Orientating.”
15.2 Discernable Information Across MFD Functions. Traffic and other information should be easily discernable across all MFD functions. For example, chevrons that represent traffic should not be confused with triangular navigation symbols; yellow (alerted) traffic should not blend in with yellow (alerted) terrain when overlaid; information that is overlaid (e.g., traffic over electronic maps) should not be cluttered.
15.3 Unambiguous Information Across MFD Functions. Symbols, colors, and other encoded information that have a certain meaning in the traffic display function should not have a different meaning in another MFD function. For example, a red traffic symbol and red terrain should both mean that immediate pilot action is required.
15.4 Traffic Alerts on MFD Functions. Traffic cautions and warnings should be indicated on the MFD, regardless of the active MFD function.
15.5 Simple Means to Display Traffic. An easy means should be provided on the MFD to select the display of traffic information.
15.6 Loss of Own-ship Directionality on an MFD. Other MFD functions in which data is positioned relative to own-ship (e.g., weather, terrain) should behave consistently with the traffic display function in the event that own-ship directionality becomes invalid (see this Appendix, Section 4.7, “Loss of Own-ship Directionality”).
16. Acceptable Traffic Surveillance Symbols. The purpose of providing traffic surveillance symbols in this AC is primarily to foster standardization and consistency in the presentation of traffic information, particularly during the early stages of ADS-B implementation in the NAS.
The emphasis here is on retaining standards and tradition (e.g., TCAS) where appropriate, yet still allowing new information encoding (e.g., traffic directionality) that supports safe and effective traffic surveillance in all ASA applications considered in this AC. The symbol set provided in this Appendix may be used for complying with this AC, and the following guidance in this Section is based on the use of these traffic symbols. Other traffic symbols may be used if they are clearly demonstrated to be safe and effective for their intended function(s).
16.1 Symbol Overview. Acceptable traffic surveillance symbols are provided in Table H-1. All traffic symbol shapes, sizes, and colors in the table are illustrative; precise attributes (e.g., color, luminance, line width, size) should be based upon human factors analysis and on applicable standards and regulations. The traffic symbols are shown here without data tags (e.g., altitude), but the data tag guidance in this Appendix (Section 7, “Traffic Data Fields”) still applies.
Table H-1 provides symbols for directional and non-directional airborne traffic. Table H-1 includes traffic symbols for TCAS/ASA correlated targets: those tracked by both TCAS and Page H - 14 APPENDI X H
ASA systems, and correlated by the ASA system to display a single target. Appendix G provides additional guidance on displays that integrate ASA and TCAS traffic.
Table H-1 Acceptable Traffic Symbol Set
16.2 Traffic Directionality. Two “basic symbol shapes” are presented in Table H-1: the diamond and the chevron. These two shapes do not necessarily represent a particular traffic data source, but, rather, discriminate two levels of traffic directionality accuracy. Although the nondirectional diamond symbol is based on TCAS standards, a diamond does not necessarily represent traffic that is tracked by TCAS. For example, a diamond can also result from traffic that is tracked only by ASA and when directionality data is invalid or below some minimum accuracy value (e.g., due to hovering) for the application.
In addition, it may be allowable for the diamond/chevron shapes to also represent other information relevant to traffic’s data quality, such as traffic position accuracy and/or its consequence on traffic’s ability to participate in an ASA application. Aggregating different (but related) information into a single symbol might be appropriate for minimizing the symbol set complexity. In such cases, a means may be provided to distinguish the aggregated symbolic information (e.g., automatic display via data tag).
16.3 Traffic Alert Levels. Color and shape encoding for the traffic symbols in Table H-1 follow an alerting philosophy that is internally consistent, and also compatible with existing TCAS and other alerting standards. The two basic symbol shapes (diamond and chevron) use the same modification rules, which apply to colors, borders, and fill.
“Advisory” alerts (flight crew awareness required, but not immediately required) are depicted by adding fill to non-alert traffic. This technique is consistent with the depiction of TCAS “proximate” traffic status. For TCAS/ASA integrated traffic displays, the indication of advisoryalert (i.e., proximate) traffic should be based on the same criteria (within 6 nm and ±1200 ft) for all displayed traffic, including targets that are not correlated. For traffic displays that do not integrate TCAS, other advisory-level criteria may apply to ASA traffic.
ASA “Caution” alerts are depicted with yellow/amber coloring and a circular border. The result is a symbol that retains the circular shape and color of the TCAS TA (Traffic Advisory) symbol, APPENDIX H Page H- 15
while remaining clearly distinct from the TCAS TA symbol. TCAS TA symbols and ASA Caution symbols are mutually discernable not only to identify that different pilot responses (or potential future responses) might be necessary, but also in part to discriminate the traffic data source in this special case of TCAS/ASA integrated displays. Otherwise, degraded pilot confidence in one system (e.g., from excessive nuisance alerts) could affect pilot confidence in the other. In the future, as ADS-B/TIS-B technology matures, this distinction of traffic alert source (TCAS vs. ASA) might no longer be recommended.
As Table H-1 illustrates, the circular border may add to the overall size of the symbol to maintain legibility. For consistency, it may be appropriate for the size of all caution and warning symbols (including TCAS TAs and RAs) to be approximately the same for a given display configuration.
In order to maintain the saliency and attention-getting properties of ASA alert symbols, it might be appropriate to ensure that the circular border is the most recognizable shape modification to the basic symbols, particularly if additional borders are used.
The specific depiction of ASA “Warning” symbols is not addressed in this AC.
16.4 Deviations from TCAS Standards. For TCAS/ASA correlated traffic, the symbols in Table H-1 reflect a departure from TCAS standards (e.g., RTCA/DO-185A), primarily with respect to the depiction of traffic directionality:
• TCAS “Other Traffic” and “Proximate Traffic” Directionality. TCAS “other traffic” and “proximate traffic” symbols may be in the shape of a chevron (vs. a diamond).
• TCAS TA Directionality. TCAS TA symbols may include a velocity vector (representing speed and direction) or directionality line (representing direction, but not speed) when directionality is valid for the application. Velocity vectors vary in length, based on traffic speed and the display range. Conversely, directionality lines have a length that are independent of traffic speed and display range. Each directionality indication type, if used, should be integrated with the presentation of other traffic information to avoid pilot confusion. Velocity vectors and directionality lines, if displayed, should be depicted without an arrowhead to avoid confusion with the vertical speed arrow in the data tag. See also this Appendix, Section 6, “Traffic Velocity Vector and Ground Track History.”
In addition to the depiction of directionality, ASA alerts are allowable providing they do not interfere with TCAS alerts (see Appendix G).
TCAS traffic that is not tracked and correlated by the ASA system should use approved TCAS symbology.
16.5 Encoding Additional Traffic Information. The traffic symbol set presented in this section might not encode all the information necessary for a given aircraft surveillance application. Additional information might also be symbolically encoded, or depicted through other means.
Table H-1 of this Appendix does not include traffic symbols that depict Selection status (e.g., selected by the flight crew; see Section 10, “Selected Traffic”), Air/Ground/Unknown status, Degraded Information status, or application-specific features, to name a few. However, the encoding of such information should be demonstrated to be compatible with the symbols in Table H-1, if used. For example, the combination of shape-following borders (e.g., used to indicate Page H - 16 APPENDI X H
Selection) and circular borders (indicating ASA caution alerts) should result in symbols that are easily discernable, are appropriately salient, and do not confuse the flight crew. As another example, the use of internal symbol modifications (e.g., center dot) or shaded fills should remain easily discernable from the standard fill shown in Table H-1.
APPENDIX H Page H- 17