Coverage estimation for symbolic model checking

Hoskote, Yatin; Kam, Timothy; Ho, Pei-Hsin; Zhao, Xudong

doi:10.1109/dac.1999.781330

Cited by 56 publications

(110 citation statements)

References 8 publications

Supporting

Mentioning

110

Contrasting

Order By: Relevance

“…As in Hoskote et al, 1999, for an implementation I, a state win I, and an observable signal q, we say that w is q-coveredby a specification S if Iw, 9 is not simulated by S. Intuitively, w is q-covered by S if flipping the value of q in w creates a behavior that is not permitted by S. As in the context of model checking, the naive algorithm computes coverage by executing a simulation computation algorithm IWI times, once for each mutant implementation. We suggest two algorithms that improve the naive algorithm.…”

Section: Introductionmentioning

confidence: 93%

“…Our work brings together the "mutant-based approach" of [Hoskote et al, 1999] and the "simulation approach" of [Katz et al, 1999). As in [Hoskote et al, 1999], coverage is measured with respect to mutant implementations.…”

Section: Discussionmentioning

confidence: 99%

“…A similar idea can be applied to formal verification, where a state is defined as "uncovered" if its labeling is not essential to the success of the verification process. This approach was first suggested by Hoskote et al, 1999. Low coverage can point to several problems.…”

Section: Introductionmentioning

confidence: 99%

“…The approach of Hoskote et al, 1999 is followed by Chockler et al,200lb, where two alternatives to the naive algorithm are presented for specifications in the branching time temporal logic CTL. The first algorithm is symbolic and computes the set of pairs (w, w') such that flipping the value of q in w' falsifies cp in w. The second algorithm improves the naive algorithm by exploiting overlaps in the many mutant implementations that we need to check.…”

Section: Introductionmentioning

confidence: 99%

“…In the full version we discuss this approach in more detail. Another approach, introduced in Hoskote et al, 1999, is to check the influence of small changes in the implementation on the satisfaction of the specification. This approach is inspired by the definition of mutation coverage in simulation-based verification [Dill, 1998].…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Coverage of Implementations by Simulating Specifications

Chockler

Kupferman

2002

Foundations of Information Technology in the Era of Network and Mobile Computing

View full text Add to dashboard Cite

In formal verification, we verify that an implementation is correct with respect to a specification. When verification succeeds and the implementation is proven to be correct, there is still a question of how complete the specification is, and whether it really covers all the behaviors of the implementation. In this paper we study coverage for simulation-based formal verification, where both the implementation and the specification are modelled by labeled state-transition graphs, and an implementation I satisfies a specificationS if S simulates I. Our measure of coverage is based on small modifications we apply to I. A part of I is covered by S if the mutant implementation in which this part is modified is no longer simulated by S. Thus, "mutation coverage" tells us which parts of the implementation were actually essential for the success of the verification. We describe two algorithms for finding the parts of the implementation that are covered by S. The first algorithm improves a naive algorithm that checks the mutant implementations one by one by exploiting the significant overlaps among the mutant implementations. The second algorithm is symbolic, and it improves a naive symbolic algorithm by reducing the number of variables in the OBDDs involved. In addition, we compare our coverage measure with other approaches for measuring coverage.

show abstract

Section: Introductionmentioning

confidence: 93%

Section: Discussionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Coverage of Implementations by Simulating Specifications

Chockler

Kupferman

2002

Foundations of Information Technology in the Era of Network and Mobile Computing

View full text Add to dashboard Cite

show abstract

Sanity Checks in Formal Verification

Kupferman

2006

CONCUR 2006 – Concurrency Theory

View full text Add to dashboard Cite

Abstract.One of the advantages of temporal-logic model-checking tools is their ability to accompany a negative answer to the correctness query by a counterexample to the satisfaction of the specification in the system. On the other hand, when the answer to the correctness query is positive, most model-checking tools provide no additional information. In the last few years there has been growing awareness to the importance of suspecting the system or the specification of containing an error also in the case model checking succeeds. The main justification of such suspects are possible errors in the modeling of the system or of the specification. The goal of sanity checks is to detect such errors by further automatic reasoning. Two leading sanity checks are vacuity and coverage. In vacuity, the goal is to detect cases where the system satisfies the specification in some unintended trivial way. In coverage, the goal is to increase the exhaustiveness of the specification by detecting components of the system that do not play a role in verification process. For both checks, the challenge is to define vacuity and coverage formally, develop algorithms for detecting vacuous satisfaction and low coverage, and suggest methods for returning to the user helpful information. We survey existing work on vacuity and coverage and argue that, in many aspects, the two checks are essentially the same: both are based on repeating the verification process on some mutant input. In vacuity, mutations are in the specifications, whereas in coverage, mutations are in the system. This observation enables us to adopt work done in the context of vacuity to coverage, and vise versa.

show abstract

”Have I Written Enough Properties?” - A Method of Comparison Between Specification and Implementation

Katz

Grumberg

Geist

1999

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. This work presents a novel approach for evaluating the quality of the model checking process. Given a model of a design (or implementation) and a temporal logic formula that describes a specification, model checking determines whether the model satisfies the specification. Assume that all specification formulas were successfully checked for the implementation. Are we sure that the implementation is correct? If the specification is incomplete, we may fail to find an error in the implementation. On the other hand, if the specification is complete, then the model checking process can be stopped without adding more specification formulas. Thus, knowing whether the specification is complete may both avoid missed implementation errors and save precious verification time. The completeness of a specification with respect to a given implementation is determined as follows. The specification formula is first transformed into a tableau. The simulation preorder is then used to compare the implementation model and the tableau model. We suggest four comparison criteria, each revealing a certain dissimilarity between the implementation and the specification. If all comparison criteria are empty, we conclude that the tableau is bisimilar to the implementation model and that the specification fully describes the implementation. We also conclude that there are no redundant states in the implementation. The method is exemplified on a small hardware example. We implemented our method symbolically as an extension to SMV. The implementation involves efficient OBDD manipulations that reduce the number of OBDD variables from 4n to 2n.

show abstract

Coverage estimation for symbolic model checking

Cited by 56 publications

References 8 publications

Coverage of Implementations by Simulating Specifications

Coverage of Implementations by Simulating Specifications

Sanity Checks in Formal Verification

”Have I Written Enough Properties?” - A Method of Comparison Between Specification and Implementation

Contact Info

Product

Resources

About