Model checking large software specifications

Abstract

Abstract-In this paper, we present our experiences in using symbolic model checking to analyze a specification of a software system for aircraft collision avoidance. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in whether model checking can be effectively applied to large software specifications. To investigate this, we translated a portion of the state-based system requirements specification of Traffic Alert and Collision Avoidance System II (TCAS II) into input to a symbolic model checker (SMV). We successfully used the symbolic model checker to analyze a number of properties of the system. We report on our experiences, describing our approach to translating the specification to the SMV language, explaining our methods for achieving acceptable performance, and giving a summary of the properties analyzed. Based on our experiences, we discuss the possibility of using model checking to aid specification development by iteratively applying the technique early in the development cycle. We consider the paper to be a data point for optimism about the potential for more widespread application of model checking to software systems.

Optimizing symbolic model checking for statecharts

“…All our TCAS II experiments were performed on a Sun Sparc 10 with 128MB of main memory, while other data were collected on a Sun Ultra 2 with 256 MB of main memory. Note that the TCAS II model analyzed was slightly different from the one examined in the initial study [3], so the data reported there should not be directly compared with the results in this paper.…”

“…Its application to nontrivial software or process-control systems is far less mature, but is increasingly promising. For example, we obtained encouraging results from applying symbolic model checking to a portion of a preliminary version of the system requirements specification of TCAS II, a complex system for mid-air collision avoidance [3]. The full requirements, comprising about 400 pages, are written in the Requirements State Machine Language (RSML) [4], a state-machine language based on statecharts [5].…”

“…Table 1 shows the results of applying the technique to the TCAS II model. Properties T1 through T4 refer to IncreaseDescent Inhibition, Function Consistency, Transition Consistency, and Output Agreement described in [3]. Property T5 refers to an assertion in [17, p. 49] that two machines, called Corrective-Climb and Corrective-Descend, should not be in their local states Yes simultaneously (comments in our version of the TCAS II requirements, however, explicitly say that the two local states are not mutually exclusive).…”

“…More interesting is the encoding of the transition relation . To illustrate the idea of the encoding, we assume the system is deterministic for simplicity; for nondeterministic systems, we refer the reader to [3]. (The techniques in Sections 4 and 5 are applicable to both deterministic and nondeterministic systems.)…”

“…Our analysis of the TCAS II model has been described in detail elsewhere [3]. In this article, we report on the Boeing EPD case study.…”