INTRODUCTION

This document sets forth minimum operational performance standards for the Airborne Collision Avoidance System Xu (ACAS Xu) equipment, designed for platforms with a wide range of surveillance technologies and performance characteristics such as Unmanned Aircraft Systems (UAS).

Incorporated within these standards are system characteristics that should be of value to users, designers, manufacturers, and installers. These characteristics are intended to accommodate the requirements of various users.

Regulatory Context

Title 14 of the US Code of Federal Regulations (14 CFR), Part 91, §91.111(a), §91.113, and §91.181 require “out-the-window” on-board pilot actions to mitigate collision risk and avoid other traffic. UAS do not have an onboard pilot to comply with these rules, so they must find alternatives. Some UAS operators use waivers with chase planes and visual ground observers to comply, while others rely on airspace segregation or remote operations to mitigate traffic incursions. However, to enable non-segregated airspace use in the National Airspace System (NAS), UAS will need “see and avoid” strategies such as a Detect and Avoid (DAA) system. In the U.S., a DAA system enables the remote pilot to “see and avoid” all traffic using sensor and guidance technology. This includes both cooperative aircraft (those that carry equipment allowing ownship to receive state information about the intruder) and non-cooperative aircraft (those that are “silent” and all state data must be determined by sensors onboard the ownship).

A DAA system comprises a Remain Well Clear (RWC) function and a Collision Avoidance (CA) function. Some implementations might exclude one of these functions; the CA function is only required per applicable mandates based on aircraft operation and weight, and most UAS are currently not subject to these mandates (see §1.2.1.1). Although the RWC and CA functions share surveillance and tracking due to practical limitations of the platform, the two functions have distinct roles. RWC is defined as the ability to detect, analyze and maneuver to avoid potential conflicting traffic by applying adjustments to the current flight path in order to prevent the conflict from developing into a collision hazard. CA is defined as a last-resort method of preventing mid-air collisions between aircraft, as directed by a Collision Avoidance System (CAS).

For Instrument Flight Rules (IFR) operations, a remote pilot using a DAA system coordinates with Air Traffic Control (ATC) when receiving RWC alerts and may employ right-of-way rules per §91.113. When not in ATC contact, the pilot (when receiving an RWC alert) has the discretion to maneuver against other traffic. CA supplements ATC separation services, and is only used as a last resort if all other mitigations fail.

The RWC function provides alerting and guidance to ensure a UAS is DAA Well Clear (DWC) of surrounding traffic, while the CA function provides alerting and guidance to ensure that UAS operation does not pose a collision risk should other mitigations fail. These defined functions are found in RTCA DO-365, Minimum Operational Performance Standards (MOPS) for Detect and Avoid Systems (Ref. CC). DO-365 contains performance requirements for RWC and ensures that RWC interoperates with CA, but does not prescribe a particular algorithm for either function. The Minimum Aviation System Performance Standards (MASPS) for the Interoperability of Airborne Collision Avoidance Systems (RTCA DO-382/EUROCAE ED-264) ensures that a CA function does not degrade the performance of existing CAS, even when integrated with an RWC function. RWC consists of Preventive, Corrective, and Warning Alerts with Suggestive Guidance, while CA consists of Warning Alerts with Directive Guidance. ACAS Xu does not have separate Warning Alerts for RWC and CA; it combines the DAA Warning Alert and Directive Guidance into a single event known as a Resolution Advisory (RA). See §1.7 for definitions of these terms.

RAs are indications provided to the flight crew and/or aircraft systems recommending maneuvers intended to avoid collisions with all threats, or restricting maneuvers to maintain existing separation. (see note under (a) in §1.1.4 regarding the term “separation”.) ICAO standards give ACAS RAs priority over ATC clearances and instructions, i.e., flight crews are instructed to follow RAs even when it conflicts with ATC guidance (Ref. ICAO Doc. 8168 – PANS-OPS, §3.2.c.2). Controllers typically have no knowledge of RAs unless notified by the flight crew via the radio. RA information is provided by ACAS to Mode S Secondary Surveillance Radars (SSRs) and ADS-B ground radios, but typically is not presented to controllers. Some alerts (e.g. wind shear warnings, stall warnings, and Ground Proximity Warning System warnings) have higher priority than ACAS RAs.

ACAS X was developed as a sucesssor to TCAS II (see §1.2.1.1). All ACAS X variants detect conflicts with intruder aircraft and issue alerts and guidance to resolve encounters. They share an underlying common design but have hardware, surveillance, and threat logic tailored for different user groups. ACAS Xa/Xo (defined in RTCA DO-385) is intended for current TCAS users. ACAS Xu is an extension of the ACAS Xa/Xo system, designed for platforms with a wider range of surveillance technologies and performance characteristics, such as UAS. ACAS Xu is a DAA solution that provides both RWC and CA functionality in compliance with RTCA DO-365B (Ref. CC). As EUROCAE and other organizations’ DAA concepts and standards are developed and matured, these ACAS Xu MOPS will need to be assessed for suitability within those environments. ACAS Xu is specified at the prescriptive algorithm level in these MOPS, and has undergone the rigorous verification and validation process (i.e. hazard analysis, stress testing, safety, and operational validation) associated with its predecessors, TCAS II and ACAS Xa/Xo.

Document Structure

This document is published in two volumes.

Section 1 of Volume I is intended to provide information needed to understand the rationale for equipment characteristics and requirements stated in the remaining sections. It describes typical equipment applications and operational goals and is the basis for the standards stated in the document. Definitions essential to proper understanding of this document are also provided in Section 1.

Section 2 of Volume I contains the minimum performance standards for the equipment. These standards define the required performance under standard operating conditions and stressed physical environmental conditions. It also details bench test procedures that demonstrate compliance, including specific bench tests for the collision avoidance logic performance.

Section 3 of Volume I describes the performance required of the installed equipment. Tests for the installed equipment are included when performance cannot be adequately determined through bench testing.

Volume II contains the Algorithm Description Document (ADD), which includes prescriptive and suggested detect and avoid algorithms for ACAS Xu. The algorithms are presented in the Julia programming language with informational commentary text. Both Volumes I and II contain certain standards and performance requirements that ensure that ACAS Xu is fully interoperable (see §1.5.5) with other airspace elements and equipment.

Display requirements are not included in this document. In UAS, the DAA display is part of the ground control station and distinct from the onboard ACAS Xu equipment package. It is considered a distinct article of equipment and its requirements are included in RTCA DO-365 (Ref. CC).

Since the measured values of equipment performance characteristics may be functions of the methods of measurement, standard test conditions and methods of test are recommended in this document.

Provisions for Potential Modifications

Volume II, Appendix L contains provisions for potential modifications of specific functionality not required per this MOPS. Some DAA stakeholders have expressed a desire to modify functionality in this MOPS to support an operation or operating mode that is beyond its current scope. For example, operation of DAA in the terminal area specified in RTCA DO-365A may require a lower or higher altitude for the RA cutoff specified in this MOPS. In Volume II, Appendix L.1, Parameterized Altitude Cutoffs, a new algorithm called ReceiveAltitudeCutoff is provided, along with instructions on how to modify the parameters file to specify an RA cutoff other than the MOPS-specified cutoff altitude. Another example is a provision to modify the scaling parameters that control the size of the ACAS Xu alerting volume, to enable increased or decreased levels of alert sensitivity with respect to specific intruders (Volume II, Appendix L.2). Places in the main body of Volume II where modifications might be made to support the incorporation of Appendix L algorithms are labeled with a comment: “# Deviation potential: Refer to ACAS Xu MOPS Vol. I section 1”. The following is the complete list of provisions for potential modifications included in Volume II, Appendix L:

• L.1: Parameterized Altitude Cutoffs – Allows for modification of the 1000-ft default RA altitude cutoff

• L.2: Offline-TABLE Scaling – Provides a way of conceptually stretching or shrinking aspects of an encounter geometry to enable increased or decreased levels of RA or RWC alerting and guidance sensitivity

• L.3: Wind Relative Coordinates – Accounts for winds aloft in the determination of horizontal RAs by using ownship airspeed and heading to calculate the relative velocity of the intruder, instead of using ground speed and track angle to determine the velocity

• L.4: Target Designation – Allows the flight crew to assign special processing to a target aircraft by designating that target (e.g. through the display), as in ACAS Xo

Neither these new algorithms nor any of the suggested modifications to the parameter file is part of the validation and verification effort associated with this MOPS. The algorithms in Volume II, Appendix L are not covered by the Test Suite (§2.4.2.2), or any of the other test procedures in §2.4, and a manufacturer that implements them would need to provide their own safety case to justify a deviation from the minimum specified in these MOPS.

In addition to the algorithms in Appendix L, the ADD contains constants, parameters and data structures that support the provisions for potential modification and are part of the prescriptive minimum algorithm. Some examples are the trm_input.intruder.designated_mode field in the STM Report (§2.4.2.2.2.5), the designation field in the TRM Report, the global constant DESIGNATION, and the data type DesignationState. These items exist to support the implementation of potential modification L.4 Target Designation. They are technically part of the minimum required algorithms, included to maintain code commonality among ACAS X variants and to ensure consistent data structures between manufacturers who implement any provisions for potential modifications and those who do not. The Test Suite does not include any specific test cases to exercise these items. (In order to specifically test the items involved in the Target Designation example, the Test Suite would need to provide inputs to ReceiveTargetDesignation in Volume II Appendix L.4, and it does not.) However, since these supporting data structures are included in the ADD, they are indirectly tested by all of the encounters in the Test Suite. Their values should remain constant or zero (e.g. the designation field in the TRM Report) and must match the expected results files in the Test Suite as long as a manufacturer does not implement any of the algorithms in Appendix L.

Intended Function

The intended function of ACAS Xu built to the specification in these MOPS is as follows: airborne traffic detection for both cooperative and non-cooperative aircraft, track processing, DAA RWC alerting and guidance for En Route airspace, and CA alerting and guidance for En Route airspace. ACAS Xu does not implement the RTCA DO-365A terminal area requirements

Operational Goals

The general operational goals of ACAS Xu are described in the following subparagraphs. Implementation of new ATC system elements under development will change communication, surveillance, and data management. This will increase the effectiveness of the existing ground-based air traffic control system. It is also apparent that a single, ground-based ATC system cannot meet the requirements of all flight conditions because of the absence of coverage in oceanic and other low traffic-density airspace. Additionally, the introduction of UAS into the NAS necessitates a function to keep UAS safely separated from other aircraft. Thus, there is a need to provide an air-to-air DAA capability on aircraft, that is independent of the ground-based system. Such a system must remain compatible with the ATC system when operating in controlled airspace.

The operational acceptability of DAA maneuvering, including vertical and horizontal response to both RWC and CA alerting and guidance, is examined in RTCA DO-365 (Ref. CC). In particular, DO-365 contains an Operational Services and Environment Description (OSED), which provides use cases that detail pilot procedure and ATC interactions in response to DAA alerting and guidance. Human factors studies were conducted as part of the requirements development process for DO-365, and ACAS Xu implements the alerting timelines and display output requirements that were formulated as a result of those studies. As these systems and operations are introduced into the NAS, their effectiveness and operational suitability will continue to be assessed.

At a minimum, equipment providing this capability must achieve the following operational goals:

a. The system must be capable of providing timely and effective DAA alerting and guidance to a pilot in order to maintain safe separation from other air traffic.

NOTE: In this document the term “separation” means physical separation, i.e., absence of NMAC, and should not be confused with the provision of ATC minimum separation.

b. Operation must be compatible with the existing ATC system and with planned evolution of the ATC system.

c. The system design must ensure that the system does not have characteristics that could adversely affect the safety of flight or interfere with other aircraft systems on the aircraft or installed on other nearby aircraft.

d. Maneuvers in response to DAA alerting and guidance provided by the system should be acceptable to both pilots and air traffic controllers.

e. The system must contain a comprehensive performance monitor function that will monitor automatically, on a continuous basis, the operating integrity of the system.

f. ACAS Xu will operate according to the assumptions and descriptions of a Class 3 DAA system in RTCA DO-365B. Specifically, DO-365B Section 1 provides a general description of a DAA system, including architectural and operational details and other assumptions. The OSED in RTCA DO-365B Appendix A provides DAA equipment class descriptions, environmental considerations, activity diagrams, and use case scenarios.

Equipment

“ACAS Xu” or “ACAS Xu equipment" as used herein includes all components or units necessary (as determined by the manufacturer or installer) for the equipment to perform its function properly. There are external systems that ACAS Xu is dependent upon that may be standardized in separate documents, but, in each case, these dependencies will be made explicit. It should not be inferred that an ACAS Xu equipment design will necessarily have all components or units in separate packages. This will depend on the specific design chosen by the manufacturer. The transponder capabilities may also be implemented as part of the ACAS Xu avionics package, but the term “ACAS Xu equipment” will refer only to the equipment needed to perform the surveillance and threat logic of the ACAS Xu system. Additional functions and components that may provide expanded equipment capabilities are identified. Other equipment features that are beyond the scope of this document may be described in future RTCA documents.

Since the equipment implementation includes a computer software package, compliance with the guidelines contained in RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, December 13, 2011, and all revisions thereto (Ref. C), is required. Compliance with the guidelines contained in RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, April 19, 2000, and all revisions thereto (Ref. X), is also required.

This document considers an equipment configuration identified in the System Overview, §1.3. Operational performance standards for functions or components that refer to equipment capabilities that exceed the stated minimum requirements are identified as optional features.

Aircraft Equipment Information Vulnerabilities

1. Aircraft equipment information vulnerabilities (such as cybersecurity risks) have been present for digital systems since the development of the Personal Computer (PC) in the late 1970s and even longer for Radio Frequency (RF) systems, and the advent of internet connectivity has substantially increased those risks. Internet and Wireless Fidelity (Wi-Fi) connectivity have become popular as a means for aircraft or equipment manufacturers to update installed avionics software, to update databases, or provide an alternate means of communicating with the flight crew or cabin (e.g., in-flight entertainment, weather, etc.).

2. In most countries, the State provides oversight of safety-of-flight systems (sometimes referred to as “authorized services”), which provide information to aircraft, such as an Instrument Landing System (ILS), VHF Omnidirectional Range Radar (VOR), Global Navigation Satellite System (GNSS), and Distance Measuring Equipment (DME), to name a few. However, the State typically does not provide oversight on “non-trusted”^[1] connectivity such as the internet, Wi-Fi, or manufacturer-supplied equipment interfaces that permit input of externally supplied data into aircraft systems. A manufacturer may expose aircraft information to vulnerability through equipment design, or introduce vulnerability as a result of being connected to a common interface. Therefore, it is important that manufacturers consider aircraft information security risk mitigation strategies in their equipment design, particularly when the equipment is responsible for an interface between the aircraft and aircraft-external systems.

3. These MOPS do not contain requirements aimed specifically at mitigating cybersecurity issues. To mitigate the risk of signal spoofing, ACAS Xu validation requirements ensure that RAs are only issued on ADS-B surveillance which has been validated by either active or ATAR surveillance, but additional strategies regarding malicious duplicate address generation or other forms of cyber-attack are outside the scope of these MOPS. It is recommended that manufacturers look at a layered approach to aircraft information security risk mitigation that includes both technical (e.g., software, signal filtering) and physical strategies. From a technical perspective, for example, this could include signal spoofing detection capabilities or more stringent, multi-factored authentication techniques such as passwords, Personal Identification Numbers (PINs), and digital certificates. From a physical perspective, a manufacturer could consider connectors that can be removed only by using special tools to prevent passenger tampering. Finally, manufacturers should consider supply chain risk management; for example, assuring that software code development contractors and their staff are properly vetted.

4. Civil aviation authorities have a regulatory interest when an applicant’s design makes use of a non-trusted connectivity where the installation can potentially introduce aircraft information security vulnerability. This requires the applicant to address not only the information security vulnerabilities and mitigation techniques for the new installation, but to also consider how vulnerability could propagate to existing downstream systems. Therefore, it is recommended that manufacturers reference their equipment security review for aircraft information and mitigation strategies in the equipment’s installation manual so that the applicant can consider them in meeting the installation regulatory requirements.

^[1] A “non-trusted” connectivity (sometimes referred to as third-party system) is any frequency or service where an Air Navigation Service Provider (ANSP) is not providing direct monitoring/protection.