Case study: Applying formal methods to the Traffic Alert and Collision Avoidance System (TCAS) II

Requirements State Machine Language (RSML) evolved from statecharts during the development of the Traffic Alert and Collision Avoidance System (TCAS) II system requirements specification. This paper describes RSML and the TCAS II system requirements specification, which was reverse-engineered from pseudocode. This case study illustrates how formal methods have been applied to a safety-critical system, improving the assurance of safety in three areas: product review, process and personnel certification, and functional testing.<<ETX>>

[1]  David Lorge Parnas,et al.  Evaluation of safety-critical software , 1990, CACM.

[2]  Nancy G. Leveson,et al.  Analyzing Software Safety , 1983, IEEE Transactions on Software Engineering.

[3]  Anthony Hall,et al.  Seven myths of formal methods , 1990, IEEE Software.

[4]  Nancy G. Leveson,et al.  Safety Analysis Using Petri Nets , 1987, IEEE Transactions on Software Engineering.

[5]  A. Pnueli,et al.  STATEMATE: a working environment for the development of complex reactive systems , 1988, [1988] Proceedings. The Third Israel Conference on Computer Systems and Software Engineering.

[6]  Amir Pnueli,et al.  What is in a step , 1989 .

[7]  Bertrand Meyer,et al.  On Formalism in Specifications , 1985, IEEE Software.

[8]  Nancy G. Leveson,et al.  Software Requirements Analysis for Real-Time Process-Control Systems , 1991, IEEE Trans. Software Eng..

[9]  Nancy G Leveson,et al.  Software safety: why, what, and how , 1986, CSUR.

[10]  Marc J. Balcer,et al.  The category-partition method for specifying and generating fuctional tests , 1988, CACM.

[11]  Richard A. Kemmerer,et al.  Integrating formal methods into the development process , 1990, IEEE Software.

[12]  Amir Pnueli,et al.  What is in a Step: On the Semantics of Statecharts , 1991, TACS.

[13]  R. Ortega,et al.  Experiences using statecharts for a system requirements specification , 1991, Proceedings of the Sixth International Workshop on Software Specification and Design.

[14]  Paul Ammann,et al.  Using Z specifications in category partition testing , 1992, COMPASS `92 Proceedings of the Seventh Annual Conference on Computer Assurance.

[15]  G. B. Finelli,et al.  The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software , 1993, IEEE Trans. Software Eng..

[16]  Nancy G. Leveson,et al.  Requirements Specification for Process-Control Systems , 1994, IEEE Trans. Software Eng..

[17]  David Garlan.  Preconditions for understanding (formal specification) , 1991, Proceedings of the Sixth International Workshop on Software Specification and Design.

[18]  David Garlan.  Preconditions for understanding , 1991, IWSSD '91.

[19]  Amrit L. Goel,et al.  Formal specifications and reliability: an experimental study , 1991, Proceedings. 1991 International Symposium on Software Reliability Engineering.

[20]  Andrew D. Zeitlin,et al.  Safety Study of TCAS II for Logic Version 6.04 , 1992 .

[21]  Ricky W. Butler,et al.  The infeasibility of experimental quantification of life-critical software reliability , 1991 .

[22]  Kathryn L. Heninger.  Specifying Software Requirements for Complex Systems: New Techniques and Their Application , 2001, IEEE Transactions on Software Engineering.

[23]  John Gannon,et al.  State-based model checking of event-driven system requirements , 1991, SIGSOFT '91.

[24]  M. S. Jaffe,et al.  Analysis capabilities for requirements specified in statecharts , 1989, IWSSD '89.