Experiences and lessons from the analysis of TCAS II

This report highlights some of the experiences gathered while analyzing the requirements specification for a commercial avionics system called TCAS II (Traffic alert and Collision Avoidance System II) for consistency and completeness. Completeness in this context is defined as a complete set of requirements, that is, there is a behavior specified for every possible input and input sequence.Under the leadership of Dr. Nancy G. Leveson, the Irvine Safety Research Group has developed a state-based requirements specification language RSML (Requirements State Machine Language) using TCAS II as a testbed [6]. The TCAS requirements specification project was very successful; RSML was well liked by all participants in the project, and the formal specification has been adopted as the official TCAS II requirements. The requirements document has been delivered to the FAA and has undergone an extensive independent validation and verification effort (IV&V).In a previous investigation, we defined procedures for analyzing state-based requirements specifications for completeness and consistency [5]. To demonstrate that our approach is feasible and is applicable to realistic systems, we have implemented a draft analysis tool and we have applied the analysis to the TCAS II requirements. The initial results from the analysis effort were encouraging [4, 5] and scaled well to a large requirements specification. The most complex parts of the TCAS requirements specification have recently been analyzed. Even though the effort was largely successful, some limitations with the approach have surfaced. Most importantly, the accuracy of the analysis algorithms needs improvement. When analyzing the most complex parts of the TCAS requirements, the number of spurious error reports can occasionally be overwhelming. Furthermore, we discovered that once the analysis has identified problems, it has been unexpectedly difficult to correct some of them.