Outside the software engineering teams conducting research and development of ACAS X — i.e., airborne collision avoidance system X — aircraft operators, pilots and other stakeholders seem most interested in its safety enhancements and user interface, one team member says. Details will continue to be refined by an RTCA special committee, EUROCAE working group and others1 until the final approval of a minimum operational performance standard, anticipated by the U.S. Federal Aviation Administration (FAA) in 2018.
Michael Castle, a systems engineer at Aurora Sciences and a contracted subject matter expert for the FAA, describes ACAS X essentially as the agency’s “solution going forward for how we are going to conduct collision avoidance.” His overview of the nine-year project was part of the Airborne Conflict Safety Forum held on June 10–11 in Brussels, Belgium (ASW, 9/14). At that time, prototype testing had focused on the new system’s capability to avoid issuing non-safety-critical (nuisance) alerts and to demonstrate a risk ratio2 significantly better than that of the traffic-alert and collision avoidance system known as TCAS II (or ACAS II) Version 7.1.
“TCAS II has been a fantastic system in terms of providing a safety margin for the airspace,” Castle said. “Since 1990, when it was mandated, there’s been no commercial [air transport] midair collision, and it’s been noted by many people that TCAS has saved situations and encounters. … We’re not here to bury TCAS, we’re here to evolve it.” In comparisons, computer simulations suggest a future probability of near midair collision (NMAC) avoidance 10 to 20 times better than TCAS II if an ACAS X–equipped ownship experiences an encounter in which separation from the intruder has been lost, he said.3
An extensively studied limitation of TCAS II is that more than 80 percent of its alerts are triggered by situations in which the ownship and the intruder actually are intentionally, safely separated. “We want to try to reduce those while also maintaining the safety factor. This is the central idea,” Castle said. “TCAS II [is] a less flexible system than what we’d like. The [software logic] changes seemed like very simple procedure changes, but it took a lot longer to do them than what we would have liked. … Accounting for new surveillance systems, new users of airspace [i.e., unmanned aircraft systems, known internationally as remotely piloted aircraft systems] and new procedures [by further upgrading would have been] a challenge, and the challenges are rooted in the structure of TCAS II.”
Technically speaking, TCAS II has relied on a rule-based pseudocode — a combination of deterministic rules and heuristics (essentially, a trial-and-error process that compares stored rules to predictable encounter geometries) — that specifies the threat logic. “Legacy TCAS first … projects the time of closest approach,” Castle said. “[The logic] decides what sense it wants to provide the alert in. Is it a climb sense or a descend [sense]? Then it tries to choose the rate that is the least disruptive [climb/descend maneuver] that also meets the thresholds.”
Overall, TCAS II functions by using highly complex logical interdependencies, and it requires uncommon expertise to modify safely. “A small set of people really understand the pseudocode … and those are the people that we have to rely upon to improve [it with] changes,” he said. Collision-avoidance experts in recent years agreed to move beyond pseudocode to a more flexible decision-making structure. Many years of peer-reviewed academic papers vetted the basic concepts, followed in 2009 by the FAA’s launch of formal research on ACAS X.
ACAS X (or more precisely, its ACAS Xo variant) has been designed to look like TCAS II in its interface and functionality so that pilots will get, for example, identical resolution advisories (RAs) on the same flight deck displays and apply the same general training to respond to them.
Expected benefits of the flexible structure include implementing reduced minimum aircraft separation, driving down the unnecessary alerts, adding new airspace-user classes as noted, and dynamically adapting future U.S. airspace to traffic.
Advanced algorithms and analytical methods today enable robust systems to make critical decisions in uncertain, dynamic environments while maintaining safety and efficiency. Forum attendees learned from Castle how that theoretical underpinning has influenced ACAS X.
“We have an uncertain situation in the airspace,” Castle said. “[We] never have perfect information. What is the best choice to be made? That’s what ACAS X was founded on. So it uses decision-theoretic safety logic and a flexible surveillance tracker.”
Three major challenges have to be addressed when designing threat logic into software that will choose among alternative ways that a collision-avoidance system should respond. “The first [challenge] is that you have imperfect sensor information, and so there’s uncertainty associated with the position and the velocity of the aircraft,” Castle said. “[Secondly,] you have dynamic uncertainty of ‘How is the pilot going to respond?’ and ‘How will the encounter develop?’ Then, the third challenge is that the system not only has to be safe, but it also has to be operationally suitable.
“We could design a perfectly safe system that just alerted [pilots] all the time — well in advance of the encounter — and, in theory, the aircraft would never come close to each other. … ACAS X tries to answer each of those by using a probabilistic sensor model, a probabilistic dynamic model and … a multi-objective utility tool … in a way that balances all these things.”
ACAS X software logic estimates the state of the ownship every second. “It’s looking at … what the ownship ‘thinks’ the world looks like,” he said. “So [it ‘asks’] ‘Where are all the intruders? Where are all the threats?’ We reduce what the world looks like down to a set of state variables.
“In the current design, we have five state variables … to define what choices we’re going to make in terms of [pilot] alerting. … A special data structure, that we call the lookup table, is pre-encoded and loaded into the avionics. And so when [the ownship has] a certain set of state variables, [ACAS X will] index into that lookup table and try to determine for each action that is possible, ‘What is the cost?’ So these lookup tables are sets of costs, and then [we] basically do a comparison. In [the third] step, [the software logic will] choose the action that has the lowest cost.”
As one example, the cost of “not alerting” the pilot was 0.8 and the cost of the pilot “leveling off” was 0.1. Because leveling off entailed the lowest cost, ACAS X selected that action. “These costs are recomputed every second by looking up the values in the lookup table,” Castle said.
Ease of upgrade was an important factor in the clean-slate design of ACAS X software logic, influenced by engineering teams’ difficulty with TCAS II changes. “With legacy TCAS, we would have [had] to change either some of the assumptions about [how] the models interoperate in terms of ownship or intruder aircraft,” he said. “We could change some of the thresholds that are embedded into TCAS II design or we could change the existing pseudocode. Each of these [choices] has different levels of complexity associated with it.”
In contrast, changing the system behavior of ACAS X is analogous to turning three knobs to tune a radio, with many combinations possible. Castle said, “One [method changes] the belief states and the state transitions. … We would possibly modify [the dynamic model] to try to change the behavior. And we could [also adjust] the off-line costs … embedded in the cost table.” The most costly off-line event — an NMAC — could be assigned a weight (value) of minus 1 in the cost table.
“Then we would have the relative weights of the other events determine the behavior of the system,” he said. “[If] an alert is [weighted as] minus 0.01, it’s 1/100th of the importance of the NMAC. We can play with these relative weights to try to tune the system to the behavior that we desire. … We give a small benefit, a small reward, for the ‘clear of conflict’ [alert, weighted as 0.0001].”
ACAS X also compares factors — such as the relative costs of strengthening an RA versus issuing a climb/descend reversal RA or changing vertical rate — to replicate the functionality of TCAS that is already familiar to today’s pilots but with fewer non-safety-critical alerts as noted, he said.
Some costs cannot be computed in advance or loaded into a lookup table, however, Castle said, referring to dynamic changes of state as the aircraft flies. For example, the altitude at which the ownship actually is flying during a given second cannot be pre-computed by the ACAS X to establish the inhibit altitude. “As the system flies, if it’s below that inhibit altitude, it won’t issue RAs,” he said.
Castle’s first metric to demonstrate ACAS X versus TCAS II performance was the probability of an NMAC for a specific ownship-intruder encounter dataset. Simulator test scenarios include combinations of ownship equipped with TCAS II or ACAS X; and the intruder equipped with TCAS II, or ACAS X, or equipped with neither but carrying a transponder. “We have formal cycles; [as of June we’re] on Run 12,” he said. “The green bars on the right side of each graph [Figure 1] represent TCAS II 7.1 performance.” Four differently colored bars on the left side of each graph show the corresponding ACAS X performance.
In the encounter dataset discussed at the safety forum, Castle said, “In each of these cases, we’re well below the probability of NMAC with TCAS [II alone].” With ACAS X combining different surveillance sources, however, “We’re something on the order of 40 [percent] to 60 percent of the probability of NMAC of TCAS II 7.1,” he said.
Another metric (Figure 2) enabled a comparison of the overall non-safety-critical alert proportion from legacy TCAS versus ACAS X. Castle said, “We reduced the [ACAS X RA rates to] between 30 and 40 percent [below] TCAS II 7.1 alert rates. [Run 12] was our first attempt to do the tuning with ADS-B [automatic dependent surveillance–broadcast] surveillance data. … We didn’t have it in the earlier runs. But there’s a trend here, which is [that] we’re getting to the point where the results are quite promising.”
A basic working principle within ACAS X engineering teams is to harness the power of computers to the extent that the computers produce optimum conflict resolutions, yet the engineers must oversee the processing and final results. “Computers are quite good at optimizing, given a set of assumptions and a set of parameters,” Castle said. “The human effort [then] is really focused on the performance metrics and evaluating how the system looks. [Humans will ask,] ‘What scenarios and encounters are important? Did the ACAS X system respond in the way that we expected and wanted?”
As for its surveillance-source flexibility, the front-end surveillance and tracking module of ACAS X converts sensor data from proprietary formats into a generalized format that has a standard interface to the threat side of the system architecture. “The threat side is where all the logic tables reside and where the choice of what TA [traffic advisory] or RA to issue is made,” he said. The significance is that ADS-B data, for example, is acceptable today and sensors not even invented yet should be compatible.
- ACAS X is now being standardized through RTCA Special Committee 147, Traffic Alert and Collision Avoidance System, and the European Organisation for Civil Aviation Equipment (EUROCAE) Working Group-75, Traffic Collision Avoidance System.
- Risk ratio is the probability of a near midair collision with a collision avoidance system divided by the probability without the system.
- When describing in-flight collision scenarios and computing threshold times/distances at which pilots should be warned to respond to a collision threat, researchers and software engineers call the aircraft flown by the pilots who would receive the alert the ownership and the conflicting-traffic aircraft the intruder.