h. If possible, verify the dynamic performance of displayed traffic by observing any available ADS-B Out, ADS-R, TCAS (if installed), or TIS-B traffic in the area.
i. Evaluate the overall CDTI system installation for satisfactory accessibility and visibility under all lighting conditions.
3-3. Flight Tests.
a. Flight tests must be conducted for each initial installation of a unique configuration of ADS-B In receiver, position sensor, ASSAP, and CDTI equipment. Flight test data from a different aircraft may be used to establish suitability in follow-on installations. Flight testing must be conducted in the range of a cooperative ADS-B Out-equipped aircraft. Flight testing should be conducted within TIS-B and ADS-R coverage. The flight test should verify the following:
(1) The other aircraft flight identification (if implemented).
(2) The ability to select a desired target aircraft (if implemented).
(3) The ability to display ground speed of the selected target aircraft (if implemented).
(4) The bearing from own-ship to the other aircraft.
(5) The distance from own-ship to the other aircraft.
(6) The relative altitude of the other aircraft.
(7) The direction of travel (ground track) of the other aircraft.
(8) The ground speed of the other aircraft (if implemented).
(9) The targets are appropriately displayed during maneuvers throughout the normal flight envelope.
(a) Movement of displayed target information should not result in objectionable jitter, jerkiness, or ratcheting effects.
(b) Movement of displayed target information should not blur, shimmer, or produce unintended dynamic effects such that the information becomes distracting or difficult to interpret.
(c) Filtering or coasting of data intended to smooth the movement of CDTI displayed target information should not introduce significant positioning errors or create system lag that makes it difficult to perform the intended task.
(d) False or redundant tracks should not occur regularly during the flight. This would indicate that the track correlation is not performing properly. This could indicate that the
14 TCAS antenna bearing is performing poorly, as an example.
b. If implemented, verify that the information provided on the CDTI display is suitable for the surface application. Depending upon which surface class has been installed, either runways only will be depicted or both runways and taxiways will be depicted.
c. If ITP is installed, evaluate the ITP functionality. The intent of ITP Flight Testing is to validate that the equipment functions properly when installed on the aircraft. It is not the intent of the ITP flight test to exhaustively test ITP geometries. Individual ITP scenarios to test each ITP geometry may be performed in a conformed ground simulator environment. The scenarios below were chosen to be representative of key operational ranges at which the equipment operates differently. The TCAS validation functionality in particular is difficult to test adequately on ground or in a laboratory environment. This is due to the challenge of creating an RF simulation that accurately reflects the in flight environment and aircraft installation effects. A flight test of ITP should successfully demonstrate the three scenarios below. For each of the scenarios, perform the steps in this paragraph. Verify that the reference traffic is being displayed as a valid reference aircraft for the ITP application. Verify that the reference aircraft is shown on the ADS-B traffic display and any dedicated ITP display. This indicates that the ADS-B surveillance portion of ITP is functioning successfully. Verify that the ITP distance computed agrees with the planned value for the flight profile. The computed value may vary from the planned value due to variations from planned aircraft speeds, range, and position. Differences should be documented and investigated after the flight for correctness. Enter CPDLC commands for an ITP request using either automatically generated messages or manually through free-text input by the pilot. If automatically generated, verify that the CPDLC text accurately represents the ITP reference aircraft information. If the local air traffic facility is equipped and able to receive the CPDLC message successfully, then exercise the CPDLC link and request an acknowledgement from ATC. If the local air traffic facility is not equipped, then the CPDLC link does not need to be exercised. CPDLC installation guidance is covered in AC 20-140() Guidelines for Design Approval of Aircraft Data Link Communication Systems Supporting Air Traffic Services (ATS). During any or all of the scenarios, alter the position, altitude, or ground speed of the aircraft in order to violate the ITP initiation criteria (refer to Table 2 below). Verify that the ITP equipment indicates that an ITP maneuver is not possible. If implemented, verify that the proper reason is indicated for the ITP maneuver not being available.
(1) Scenario 1 ITP Reference aircraft < 30nm: Perform a flight test with two aircraft, one being the Ownship aircraft and the other being the Reference aircraft. Position the aircraft so they are in-trail between 20 and 30 nautical miles and within 15 knots of ground speed. If TCAS validation is implemented, the ITP equipment will use TCAS measurements (range, bearing, and altitude) to validate ADS-B position for version 0 and version 1 targets.
(2) Scenario 2 ITP Reference aircraft > 30nm: Position the aircraft so they are in-trail greater than 30 nautical miles, but within the capability of the manufacturer’s TCAS to get occasional replies, and within 15 knots of ground speed. If TCAS validation is implemented, the ITP equipment will use TCAS measurements of opportunity (range, bearing, and altitude) to validate ADS-B position for version 0 and version 1 targets when able. At this range, TCAS may not be able to sustain a track due to spotty transponder replies. It is the
15 responsibility of the TCAS manufacturer to provide the approximate maximum range at which TCAS measurements are still available.
(3) Scenario 3 ITP Reference aircraft outside of TCAS range: Position the aircraft so they are on similar tracks (within 45 degrees), outside of the manufacturer provided TCAS measurement range, and within 15 knots of ground speed. In this geometry, TCAS validation will be unavailable.
Table 2. ITP Maneuver Criteria
ITP Speed/Distance Criteria ITP Distance >= 15 NM and Closing Ground Speed Differential <= 20 knots or ITP Distance >= 20 NM and Closing Ground Speed Differential <= 30 knots Relative Altitude Criteria Difference in altitude between the ITP and Reference Aircraft is less than or equal to 2000 feet Similar Track Criteria Difference in track angles between ITP and Reference Aircraft less than +/- 45 degrees Position Accuracy for ITP and Reference Aircraft ITP and Reference Aircraft data with horizontal position accuracies of at least 0.5 NM (95%) Position Integrity for ITP and Reference Aircraft ITP and Reference Aircraft data with horizontal position integrity bounds of 1.0 NM @ 1x10E-05 Velocity Accuracy for ITP and Reference Aircraft ITP and Reference Aircraft data with horizontal velocity accuracies of at least 10 m/s (19.4 knots) 95% Closing Mach Differential (ATC Crosscheck) Closing Mach Differential equal or less than 0.06 Mach
Appendix 1
A1-1 Appendix 1. Latency Analysis
1. Purpose. The purpose of this appendix is to provide guidelines on accomplishing a latency analysis of your ADS-B In system to demonstrate that it complies with the end-to-end budget for ADS-B applications. It is important to minimize latency and the uncertainty of latency (i.e., how the latency differs between updates) at the system integration level. The easiest way to ensure this design goal is met is to provide a direct connection between the position source and the ADS-B equipment. Any other system blocks between them will increase latency and uncertainty. In some cases, an increase in uncertainty can have a more detrimental effect than the latency itself. Refer to RTCA/DO-317A appendix J for additional information on the interfaces described below.
2. Analysis. For ADS-B In installations, the latency analysis consists of two parts; the traffic latency analysis and the own-ship position latency analysis. Together, these analyses must show:
a. That the total latency allowance is not exceeded and,
b. The own-ship position and traffic positions are estimated to a time of applicability within 1 second of the time of display.
Note: Manufacturers should ensure installation instructions adequately address latency to assist the installer.
3. Traffic Latency Analysis. Figure 2 depicts a block diagram of the ADS-B In system and the recommended latency budget allocated to each block. To demonstrate that the system does not exceed the total latency budget, determine the applicable latencies for each component and total all of the individual component latencies. You must include all sources of latency, including, but not limited to: the ADS-B receiver, the ASSAP equipment, the CDTI equipment, and any intermediary devices. The total for your system between interface D and interface G must not exceed 3.5 seconds. It is acceptable for a manufacturer to allocate the total budget among their system components as needed. However, this design choice will limit the flexibility of pairing their equipment with other manufacturers. In calculating worst case latency, the traffic latency analysis must assume the simultaneous processing of the maximum number of traffic symbols the system is designed to support.
4. Traffic Time of Applicability Analysis. Demonstrate by analysis that the traffic displayed to the flight crew has been estimated forward to be within 1 second of the time of display. For instance, if the latency analysis in the previous paragraph comes to 2.6 seconds, the traffic must be estimated forward 2.6 seconds +/- 1 second by the system prior to displaying that traffic.
The actual estimate for each individual piece of traffic will vary as the received ADS-B messages arrive asynchronously. The analysis must demonstrate that this variation is handled appropriately. The analysis must also demonstrate that any variation in the latency due to processes within the equipment chain does not cause the time of applicability to violate the 1 second tolerance. If different vendors’ equipment are paired together to create a complete system, latency performance data for each system component must originate with the
Appendix 1
A1-2 component manufacturer. Reverse engineering another vendor’s latency performance is not an acceptable means of compliance. Manufacturers are encouraged to include their individual component latency performance in an installation manual to facilitate proper ADS-B system integrations.
Figure 2. Traffic Latency Block Diagram
5. Own-Ship Position Latency Analysis. Refer to figures 3 and 4 which depict block diagrams of two potential implementations of ADS-B In system architectures with recommended latency budgets allocated to each block. For either architecture, the ASSAP equipment must receive the own-ship position data with less than 600 ms of compensation error and less than 1 second of total latency. For this portion of the analysis, total latency starts at the time of measurement of the position source (A3) and ends when ASSAP has received the complete position update (B3). Own-ship total latency at the time of display (G) must not exceed 3.5 seconds.
6. Own-Ship Position Time of Applicability. Demonstrate by analysis that the own-ship position displayed to the flight crew has been estimated forward to be within 1 second of the time of display. The 1 second tolerance must include any compensation error present in the system between interfaces A3 and G. Determine the total latency from the position source time of measurement (A3) to the time of display (G). This latency will depend on the path of own-ship position data and vary by system architecture. Refer to Figure 3 and Figure 4 for examples of two potential architectures. The analysis must demonstrate that any variation in the latency due to processes within the equipment chain does not cause the time of applicability to violate the 1 second tolerance. If different vendors’ equipment are paired together to create a complete system, data for each system component must originate with the component manufacturer. Reverse engineering another vendor’s latency performance is not an acceptable means of compliance. Manufacturers are encouraged to include their individual component latency performance in an installation manual to facilitate proper ADS-B system integrations.
Appendix 1
A1-3
Figure 3. Own-Ship Latency Block Diagram Simple Architecture
Figure 4. Own-Ship Latency Block Diagram Alternate Architecture
Appendix 2
A2-1 Appendix 2. Symbol Requirements for the CDTI
1. Traffic Symbols and Variations. The “basic” traffic symbol is used to depict airborne traffic. Traffic symbols can be modified from the basic symbol to provide special status information, such as on-ground, selected, designated, and alerted. The symbols depicted are examples. The line width, physical size, and hue of the figures are not requirements. The requirements are stated in the associated text.
a. Basic Directional (see Figure 5).
(1) If directionality is valid, the basic directional traffic symbol must be depicted with an arrowhead shape oriented by the directionality.
(2) The color must be cyan or white.
(3) The color must be the same color as the basic non-directional symbol.
(4) The color should not be the same color as the own-ship symbol.
(5) For displays that do not integrate aircraft surveillance applications system (ASA) with TCAS, the symbol may be filled or unfilled.
(6) For TCAS/ASA-integrated systems, the symbol must be unfilled.
Figure 5. Basic Directional Symbol
b. Basic Non-Directional (see Figure 6).
(1) If directionality is invalid, the basic non-directional traffic symbol must be depicted with a diamond shape.
(2) The color must be cyan or white.
(3) The color must be the same color as the basic directional symbol.
(4) The color should not be the same color as the own-ship symbol.
(5) For displays that do not integrate ASA with TCAS, the symbol may be filled or unfilled.
(6) For TCAS/ASA-integrated systems, the symbol must be unfilled.
Appendix 2
A2-2 Figure 6. Basic Non-Directional Symbol
c. Traffic Directionality. If the traffic symbol indicates directionality, the directionality of the traffic symbol must be displayed relative to the display orientation.
Note: The traffic directionality in air is based on traffic ground track angle, and not necessarily traffic heading. This is important for monitoring traffic such as helicopters that can fly backwards and to account for winds.
d. Traffic Application Capability. The traffic symbol may provide an indication of traffic application capability.
Note 1: Traffic information that does not meet the minimum requirements for enhanced visual acquisition (EVAcq) should not be sent to the CDTI display from ASSAP.
Note 2: ASSAP may provide TCAS-only data that does not support EVAcq. TCAS data will still be displayed.
e. Traffic On-Ground Status (see Figure 7).
(1) If traffic is on-ground, the basic traffic symbol must be modified by changing the color.
(2) The color may be brown/tan.
(3) The size of on-ground traffic symbols may be decreased for additional encoding, and/or to reduce clutter.
(4) The symbol may be filled or unfilled.
Note: Additionally, altitude information is removed from the data tag.
Figure 7. Directional and Non-directional On-ground Traffic Symbols
Appendix 2
A2-3
f. Basic Ground Vehicle
(1) The basic Ground Vehicle symbol must be depicted as a top-down wheeled rectangular shape.
(2) The color should be the same as that used for the basic Traffic On-Ground symbol. The color may be brown/tan.
(3) Ground Vehicle directionality may be indicated by adding a triangular shape to one end of the rectangle, and orienting the entire symbol by directionality. Figure 8 provides an example notional depiction.
(4) The symbol may be filled or unfilled.
Figure 8. Basic Surface Vehicle Symbol
2. Alerts. The following requirements, per TSO-C195a, apply generally to CDTI-displayed alerts based on both ASA and TCAS systems. Additional TCAS-specific alert symbol requirements are provided in Appendix 2 section 3.
a. Traffic that triggers an alert must be indicated on the Traffic Display with a symbol variation. The following requirements only apply to the alerted traffic symbol:
(1) If traffic directionality is valid, directionality information must not be removed during alerts.
(2) The traffic symbol must change to amber/yellow for caution level alerts.
(3) The traffic symbol must change to red for warning level alerts.
(4) For traffic without valid directionality:
(a) If traffic has a caution level alert, the traffic symbol may be modified by changing the shape to a circle.
(b) If traffic has a warning level alert, the traffic symbol may be modified by changing the shape to a square.
(5) For traffic with valid directionality:
Appendix 2
A2-4
(a) If traffic has a caution level alert, the traffic symbol may be modified by changing the shape to a circle with a directional inlay.
(b) If traffic has a warning level alert, the traffic symbol may be modified by changing the shape to a square with a directional inlay.
Note: Caution and warning level alerts may use the same traffic symbols as TCAS traffic advisories and resolution advisories, respectively.
(See Appendix 2 section 3)
(6) For airborne applications, 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.
b. Proximate Traffic (see Figure 9).
(1) For TCAS/ASA integrated systems, the traffic symbol must indicate airborne TCAS proximate status.
(2) If proximate traffic is displayed, the basic traffic symbol must be displayed as filled. Figure 9 provides example notional depictions.
Note: This requirement is to be consistent with TCAS symbol convention.
Figure 9. Proximate Directional and Non-directional Proximate Traffic Symbols
c. Selected Traffic.
(1) Selected traffic is traffic that is selected by the flight crew. Traffic selection results in display of additional traffic information beyond what is presented in the minimum data tag, and may enable other functions (e.g., designating traffic).
(2) If traffic selection is implemented:
(a) There must be some means of distinguishing the selected traffic from other traffic on the traffic display.
Appendix 2
A2-5
(b) A border must not be used to indicate selected traffic.
Note 1: A border is a discernable line that surrounds an existing symbol. Border types include fixed-shape or conformal.
Note 2: Borders are reserved for depicting designated traffic (see Figure 10).
(3) When traffic is selected, additional information on that traffic must be displayed in a data block or a data tag.
Note: Generally, selecting traffic will bring up the additional information in a data block, but a data tag can also be used for this purpose.
(4) There must be an indication of off-scale selected traffic.
Note: A Selected half-symbol at the display edge and appropriate bearing is one acceptable method of indication.
d. Designated Traffic (see Figure 10).
(1) Designated traffic is traffic upon which a designated application is to be performed. For example, in visual separation on approach (VSA), the traffic to be followed may be displayed as “designated” so that the application and the flight crew both know the specific traffic upon which to act.
(2) If traffic designation is implemented:
(a) There must be some means of distinguishing the designated traffic from other traffic.
(b) If traffic is designated, the basic traffic symbol should be modified by adding a shape-conforming border. Figure 10 provides a notional example.
Figure 10. Directional and Non-directio nal Designated Traffic Symbols
(c) There must be an indication of off-scale designated traffic.
Appendix 2
A2-6 Note: A half-symbol at the display edge and appropriate bearing is one acceptable method of indication.
(d) The loss of “designated” status (e.g., due to signal loss or invalid data) must be indicated to the flight crew.
3. TCAS Alert Symbology for TCAS/ASA-Integrated Systems.
a. If traffic directionality is valid, directionality information must not be removed during a TCAS traffic advisory or resolution advisory.
Note: Directionality information, if available, may assist the flight crew in visual search and identification of the alerted traffic.
b. Traffic Advisories (see Figure 11).
(1) If traffic has a TA, the traffic symbol must be modified by changing the color to amber/yellow, and changing the shape to a circle.
(2) Traffic with valid directionality must include a directional inlay.
(3) The size of TA traffic symbols may be increased to accommodate the shape modification.
(4) Line widths and fill may be changed to improve color interpretation and saliency.
Figure 11. Traffic Advisory Symbols
c. Resolution Advisories (RAs) (see Figure 12).
(1) If traffic has an RA, the traffic symbol must be modified by changing the color to red, and changing the shape to a square.
(2) Traffic with valid directionality must include a directional inlay.
(3) The size of RA traffic symbols may be increased to accommodate the shape modification.
(4) Line widths and fill may be changed to improve color interpretation and saliency.