An LTL SAT Encoding for Behavioral Diagnosis Ingo Pill 1 , Thomas Quaritsch 1 1 Institute for Software Technology, Graz University of Technology, Inffeldgasse 16b/II, Graz, 8010, Austria {ipill,quaritsch}@ist.tugraz.at ABSTRACT Assisting designers in writing high-quality spec- ifications is an important step towards minimiz- ing product defects and rework efforts. Draw- ing on the attractive performance of satisfiability solvers, in this paper, we present a SAT encod- ing that enables an efficient model-based diagno- sis of LTL specifications in the context of behav- ioral samples (traces). The resulting diagnoses at operator level and our experimental results illus- trate our approach’s viability and attractiveness. 1 INTRODUCTION Industrial data show that about 50 percent of product defects result from flawed requirements and up to 80 percent of rework efforts can be traced back to require- ment defects (Wiegers, 2001). Surprisingly enough, traditionally, research has been focusing on verifying designs against their specifications, and seldom aimed at verifying a specification’s quality or assisting de- signers in their formulation. Recently, specification development has been gaining attention in a formal context. Coverage and vacuity can pinpoint to specifi- cation issues (Fisman et al., 2009; Kupferman, 2006), and recent work regarding unsatisfiable cores for Lin- ear Temporal Logic (LTL) specifications (Schuppan, 2012) provides hints at contradicting clauses in a specification’s model. Furthermore, formal specifi- cation development tools like RAT (Pill et al., 2006; Bloem et al., 2007a) help designers in understanding formal semantics via a user-friendly interface. They allow a user, for example, to explore a specification’s semantics in the scope of behavioral examples (i.e. traces, a common concept known well enough), where a user can also ask concrete questions. This way the designer can grasp the intrinsics of the specification language, and by manual inspection of its behavioral aspects she gains confidence in (and a deep under- standing of) developed specifications. Diagnostic rea- soning in case things are not as expected could enable further automation and would help in enhancing user experience. In this context, let us consider the fol- lowing development step example for an arbiter, taken from (Pill et al., 2006). The two-line arbiter’s in- and outputs consist of two request lines r 1 and r 2 and the corresponding grant lines g 1 and g 2 . At a certain step, the designer established the following four require- ments (see Section 2 for an introduction to LTL): R 1 : requests on both lines must be granted eventually ∀i ∈{1, 2} : G (r i → F g i ) R 2 : no simultaneous grants for lines 1 and 2 G ¬(g 1 ∧ g 2 ) R 3 : no initial grant before a request ∀i ∈{1, 2} :(¬g i U r i ) R 4 : no additional grants until there is a new request ∀i ∈{1, 2} : G (g i → X (¬g i U r i )) In order to check the specification, the designer comes up with the following supposed witness (i.e. a trace τ that should be included in the specification) featuring a simultaneous initial request and grant for line 1: τ =  r 1 , ¬r 1 g 1 , ¬g 1  ¬r 1 ¬g 1  ω Please note that for clarity of the running example, we omit the correct trace parts for line 2, while, as sup- posed, the designer and our approach would consider the whole trace. Using a requirements tool like RAT, the designer would recognize that, unexpectedly, her trace is not featured by the specification. Diagnostic reasoning offering explanations why this is the case (in the example, the operator U in R 4 should be replaced by its weak cousin W) would be a valuable asset in this situation. To this purpose, we propose in this paper an efficient SAT encoding for LTL in the scope of infinite traces, and use it as basis for diagnosing issues at specifica- tion and trace level. For our encoding we temporally unfold a specification’s obligations to be satisfied by a trace, where similar to the encoding Schuppan uses in (Schuppan, 2012) or that of Heljanko et al. in (Hel- janko et al., 2005), the rationale behind the unrolling are the well known expansion rules as present in LTL tableaus and automata constructions (e.g. (Clarke et al., 1994; Somenzi and Bloem, 2000)). In our specific 1