Using abstraction and model checking to detect safety violations in requirements specifications

Abstract

Abstract-Exposing inconsistencies can uncover many defects in software specifications. One approach to exposing inconsistencies analyzes two redundant specifications, one operational and the other property-based, and reports discrepancies. This paper describes a "practical" formal method, based on this approach and the SCR (Software Cost Reduction) tabular notation, that can expose inconsistencies in software requirements specifications. Because users of the method do not need advanced mathematical training or theorem proving skills, most software developers should be able to apply the method without extraordinary effort. This paper also describes an application of the method which exposed a safety violation in the contractor-produced software requirements specification of a sizable, safety-critical control system. Because the enormous state space of specifications of practical software usually renders direct analysis impractical, a common approach is to apply abstraction to the specification. To reduce the state space of the control system specification, two "pushbutton" abstraction methods were applied, one which automatically removes irrelevant variables and a second which replaces the large, possibly infinite, type sets of certain variables with smaller type sets. Analyzing the reduced specification with the model checker Spin uncovered a possible safety violation. Simulation demonstrated that the safety violation was not spurious but an actual defect in the original specification.

High assurance human-centric decision systems

“…An advantage of our approach is that the synthesized requirements models can be analyzed using the SCR toolsvalidated using simulation [12], analyzed automatically for consistency and completeness [14], and verified formally using model checking [13], theorem proving [12], composition [17], and automatically generated invariants [21].…”

On Software Certification: We Need Product-Focused Approaches

“…There have been some notable industrial and military applications of tool supported formal methods, especially for the analysis of software systems requirements (e.g., [11,12,13,14]). Unfortunately, the formal methods advocates concerned, typically were not given the opportunity to fully integrate their techniques with the overall software engineering process.…”

An Abductive Approach for Analysing Event-Based Requirements Specifications

“…For example, in Table 1 the mode transition defined in the second row is caused by the occurrence of conditioned event "@F(Ignited)" whose condition is that "Running" is false. Different semantics have been used for conditioned events [11], all of which are expressible in our Event Calculus approach. In this case study, we have adopted the following interpretation.…”

“…[20,27,28]). Most techniques based on model checking facilitate automated analysis of requirements specifications and generation of counterexamples when errors are detected [2,4,11]. However, in contrast to our approach they presuppose complete descriptions of the initial state(s) of the system to compute successor states.…”

“…For example, in the context of SCR, [11] illustrates how both explicit state model checkers, such as Spin [12], and symbolic model checkers, like SMV [19], can be used to detect safety violations in SCR specifications. The first type of model checking verifies system invariants by means of state exploration.…”