What TCAS can tell us about AF447 (Updated 27 Sept 09)
The BEA interim report on the AF447 accident confirms that the Traffic Alert and Collision Avoidance System (TCAS) had become inoperative during the early part of the event sequence for an, as yet, un-identified reason. The explanation may actually be fairly straight forward and lie within the fault tolerance requirements of the TCAS specification.
The BEA interim report on the AF447 disaster (BEA, 2009) contains the complete set of CMC messages received in the final moments of AF447 and an explanation by the BEA of what the various message codes mean. The report confirms initial reports that the Traffic Alert and Collision Avoidance System (TCAS) had become inoperative during the early part of the event sequence for a reason as yet un-identified by the BEA. In fact the explanation is actually fairly straight forward and relates to the TCAS system’s fault tolerance processing. An aircraft’s TCAS uses aircraft Air Data Reference (ADR) pressure altitude, provided by the Mode S transponder as an input to the collision avoidance processing (RTCA 97).
Obviously altitude data errors can lead to a false output so the TCAS Minimum Operational Performance Standard (MOPS) requires that TCAS incorporate a barometric altitude credibility monitor that will reject barometric altitude changes of greater than a specified acceleration limit and the aircraft track is then coasted (RTCA 99). The MOPS also requires that TCAS become inoperative when the System Performance Monitor function detects that the own aircraft track has coasted for 5 seconds (RTCA 99). Rapid changes in barometric pressure were previously experienced in the Air Caraibes F-OFDF icing incident (1). So a large enough change in barometric altitude due to icing, such as occurred in the Air Caraibes incident, could cause TCAS to declare itself inoperative, as was seen in the AF447 event data (2).
TCAS logic was revised in a change to Version 7 (CP 98) to maintain own track under the combined conditions of aggressive pilot manouevre and bad altitude inputs. This resulted in an altitude credibility window with a half-width of 195 ft when track softness is minimum, 325 ft when softness is maximum, and 260 ft in-between
Unfortunately air data is not the only input to TCAS that could trigger a TCAS fault state we cannot say with absolute certainty that a rapid altitude change is the culprit (3) . But, working on the principal that if you hear hoof beats in Central Park, you probably shouldn’t expect to see zebra rounding the corner, I think we’re safe in assuming that altitude related data is the causal factor here (4) (5).
The interesting point about the TCAS failure is that if the air data was sourced from a specific ADR it strongly infers the failure of that specific ADR. If transponder altitude was derived from ADR 1 this would support the hypothesis that ADR1 failed early in the event seqence. Another interesting point is that the Mode S transponder would have been outputting AF447s altitude data (along with other data) to other aircraft in the area. I’m not aware whether this sort of track data is recorded by other aircraft, if not this might be a consideration for further development of aircraft data recording systems.
The unexpected nature of the TCAS failure also neatly illustrates that the implementation of varying fault tolerance strategies across a system can lead to, ‘surprise’ behaviour when a system experiences a challenge. This is of recurring concern to system architects as we rarely build a system from scatch and can usually expect elements of the system to be updated/replaced asynchronously.
1. For installation into older aircraft where pressure altitude information was supplied in Gillham’s code format, detection of an altitude source or encoder failure was also required. Normally this was satisfied by the use of redundant altitude sources (JAA 2001).
2. In the F-OFDF incident the onboard TCAS did not declare itself inoperative so it should be fairly straightforward to cross check the altitude changes in that incident against that aircraft’s TCAS performance monitor implementation. A similar check could be performed for other incidents involving unreliable air-speed and TCAS equipped aircraft.
3. For example Honeywell’s ACS-5059 TCAS manual indicates that aircraft heading and attitude could also cause a TCAS fault state (Honeywell 2001).
4. During the Air Cairaibes incident barometric altitude was seen to initially rapidly vary from 35,000 to 34,700 ft (Houang 2001).
5. Updated 27 Sept 09. Re-reading the RTCA documents an aggressive flight manoeuvre that exceeds the RTCA worst case scenario could also trigger the TCAS performance monitor, especially in combination with the fluctuating barometric altitude. The RTCA MOPS states an initial descent at 6,000 fpm, then, after a short time, a vertical rate reversal with an acceleration that builds up at the high rate of 8 ft/s3 (jerk) to a maximum acceleration of 40 ft/s2 (1.25g).
BEA, Interim report,on the accident on 1st June 2009, to the Airbus A330-203, registered F-GZCP, operated by Air France flight AF447 Rio de Janeiro – Paris, Report Number f-cp090601ae, July 2009.
Honeywell, TCASII/ACASII Collision Avoidance System User’s Manual, ACS-5059 , Revision 5, 2001.
Houang, H., Air Cairabes Memorandum, Givrage Des Sonde, 8 December 2001.
Joint Aviation Administration, LEAFLET NO 13: Certification of Mode S Transponder Systems for Elementary, Surveillance, 2001.
RTCA SC-186, TCAS Change Proposal CP 98, 23 Sept 1999.
RTCA SC-186, Draft TCAS II Minimum Operational Performance Standards (MOPS) Version 7 (DO-185B), 27 April 1997.