A Specification Language and a Verification Engine for Reliable Reactive System Development Tevfik Bultan Department of Computer Science University of California, Santa Barbara

Towards Verifiable Specification Languages Tevfik Bultan Department of Computer Science University of California, Santa Barbara

A Set of Tools for Specification and Verification of Reactive Systems Action Language specification Parser Verifier Composite Symbolic Library Code Generator OmegaLibraryCUDDPackage Verified code

Applications Safety-critical system specifications –SCR (tabular), Statecharts (hierarchical state machines) specifications [Bultan, Gerber, League ISSTA98, TOSEM00] Concurrent programs –Synthesizing verified monitor classes from specifications [Yavuz-Kahveci, Bultan] Protocol verification –Verification of parameterized cache coherence protocols using counting abstraction [Delzanno, Bultan CP01] Verification of workflow specifications –Verification of acyclic decision flows [Fu, Bultan, Hull, Su]

Composite Model Checking Can model checking be extended to verification of specifications with arithmetic constraints? –[Bultan, Gerber, Pugh CAV97, TOPLAS99] Using Presburger (linear) arithmetic constraints for model checking infinite state systems Problem: Most specifications have a combination of integer, boolean and enumerated variables –[Bultan, Gerber, League ISSTA98, TOSEM00] Composite model checking: Model checking with type-specific symbolic representations Uses Presburger arithmetic constraints and BDDs together

Composite Symbolic Library [Yavuz-Kahveci, Tuncer, Bultan TACAS01] A symbolic manipulator that can handle boolean and integer variables (linear arithmetic constraints) Built on top of other symbolic manipulators –Omega Library [Pugh et al.]: a Presburger arithmetic formula manipulator (based on polyhedral representations) –CUDD package [Somenzi et al.]: a Boolean logic formula manipulator (a BDD package) Uses a disjunctive representation to combine arithmetic constraints with BDDs Uses an object oriented design –Every symbolic representation is derived from an abstract class We wrote wrappers around Omega Library and CUDD package –Can be extended to other variable types if a symbolic representation is provided for them

Action Language [Bultan ICSE00] [Bultan, Yavuz-Kahveci ASE01] Initial goal –To develop an input specification language for our composite model checker Broader perspective –Develop a low level specification language for model checking –The language should be able to “handle” different high level specification languages

Outline Specification Language: Action Language –Synchronous vs. asynchronous composition –Translating hierarchical and tabular specifications to Action Language Verification Engine –Constraint-based verification –Composite Symbolic Library Applications –Synthesizing verified monitor classes –Verification of parameterized cache coherence protocols –Verification of workflow specifications Related, Current and Future Work

Model Checking View Every reactive system –safety-critical software specification, –cache coherence protocol, –mutual exclusion algorithm, etc. is represented as a transition system: – S : The set of states – I  S : The set of initial states – R  S  S : The transition relation

Model Checking View Properties of reactive systems are expressed in temporal logics Invariant(p) : is true in a state if property p is true in every state reachable from that state –Also known as AG Eventually(p) : is true in a state if property p is true at some state on every execution path from that state –Also known as AF

Action Language A state based language –Actions correspond to state changes States correspond to valuations of variables –Integer (possibly unbounded), boolean and enumerated variables –Parameterized constants (verified for every possible value of the constant) Transition relation is defined using actions –Atomic actions: Predicates on current and next state variables –Action composition: synchronous (&) or asynchronous (|) Modular –Modules can have submodules –Modules are defined as synchronous and asynchronous compositions of its actions and submodules

Actions in Action Language Atomic actions: Predicates on current and next state variables –Current state variables: reading, nr, busy –Next state variables: reading’, nr’, busy’ –Logical operators: not (!) and (&&) or (||) –Equality: = (for all variable types) –Linear arithmetic:, >=, <=, +, * (by a constant) An atomic action: !reading and !busy and nr’=nr+1 and reading’

An Action Language Specification module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer() boolean writing; initial: !writing; wEnter: !writing and nr=0 and !busy and busy’ and writing’; wExit: writing and !writing’ and !busy’; Writer: wEnter | wExit; endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule

A Closer Look module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer()... endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule S : Cartesian product of variable domains defines variable domains defines the set of states the set of states I : Predicates defining the initial states the initial states R : Atomic actions of the Reader Reader R : Transition relation of Reader defined as asynchronous composition of its atomic actions R : Transition relation of main defined as asynchronous composition of two Reader and two Writer processes

Asynchronous Composition Asynchronous composition is equivalent to disjunction if composed actions have the same next state variables a1: i > 0 and i’ = i + 1; a2: i <= 0 and i’ = i – 1; a3: a1 | a2 is equivalent to a3: (i > 0 and i’ = i + 1) or (i <= 0 and i’ = i – 1);

Asynchronous Composition Asynchronous composition preserves values of variables which are not explicitly updated a1 : i > j and i’ = j; a2 : i <= j and j’ = i; a3 : a1 | a2; is equivalent to a3 : (i > j and i’ = j) and j’ = j or (i <= j and j’ = i) and i’ = i

Synchronous Composition Synchronous composition is equivalent to conjunction if two actions do not disable each other a1: i’ = i + 1; a2: j’ = j + 1; a3: a1 & a2; is equivalent to a3: i’ = i + 1 and j’ = j + 1;

Synchronous Composition A disabled action does not block synchronous composition a1: i < max and i’ = i + 1; a2: j < max and j’ = j + 1; a3: a1 & a2; is equivalent to a3: (i = max & i’ = i) and (j = max & j’ = j);

Statecharts [Harel 87] Hierarchical state machines States can be combined to form superstates OR decomposition of a superstate –The system can be in only one of the OR states at any given time AND decomposition of a superstate –The system has to be in both AND states at the same time Transitions –Transitions between states

Statecharts to Action Language Statecharts transitions (arcs) correspond to actions OR states correspond to enumerated variables and they define the state space Transitions (actions) of OR states are combined using asynchronous composition Transitions (actions) of AND states are combined using synchronous composition

Statecharts to Action Language module main() enumerated Alarm {Shut, Op}; enumerated Mode {On, Off}; enumerated Vol {1, 2}; initial: Alarm=Shut and Mode=Off and Vol=1; t1: Alarm=Shut and Alarm’=Op and Mode’=On and Vol’=1; t2: Alarm=Shut and Alarm’=Op and Mode’=Off and Vol’=1; t3: Alarm=Op and Alarm’=Shut; t4: Alarm=Op and Mode=On and Mode’=Off; t5: Alarm=Op and Mode=Off and Mode’=On;... main: t1 | t2 | t3 | (t4 | t5) & (t6 | t7); endmodule Alarm Shut Op On Off 1 2 ModeVol t1 t2 t3 t4 t5t6t7 Preserves the structure of the Statecharts specification

SCR [Courtois and Parnas 93], [Heitmeyer et al. 96] Tabular specifications –Mode transition tables –Condition tables –Event tables Events =  c  c’ –In action language: !c and c’ WHEN d =  c  c’  d –In action language: !c and c’ and d

SCR to Action Language Each row in an SCR table corresponds to an action The transition relation of a table is defined by asynchronous composition of actions that correspond to its rows The transition relation of the whole system is defined by synchronous composition of transition relations of tables

SCR to Action Language module main() enumerated Heater {On, Off}; enumerated AC {On, Off}; integer temp; parameterized integer low, high; initial: low<=temp<=high and Heater=AC=Off; r1: !(temp<low) and temp’<low and Heater=Off and Heater’=On; r2: !(temp>=low) and temp’>=low and Heater=On and Heater’=Off; t_heat: r1 | r2;... main: t_heat & t_AC; endmodule Old ModeEventNew Mode <  low) Off Old ModeEventNew Mode >  high) Off Heater AC

Outline Model Checking Specification Language: Action Language –Synchronous vs. asynchronous composition –Translating hierarchical and tabular specifications to Action Language Verification Engine –Constraint-based verification –Composite Symbolic Library Applications –Synthesizing verified monitor classes –Verification of parameterized cache coherence protocols –Verification of workflow specifications Related, Current and Future Work

Model Checking Given a program and a temporal property p: Either show that all the initial states satisfy the temporal property p –set of initial states  truth set of p Or find an initial state which does not satisfy the property p –a state  set of initial states  truth set of  p

Temporal Properties  Fixpoints Invariant(p) pppp Initialstates initial states that violate Invariant(p) Backwardfixpoint Forwardfixpoint Initialstates states that can reach  p i.e., states that violate Invariant(p) reachable states of the system pppp backwardImage of  p of  p reachable states that violate p forward image of initial states

Symbolic Model Checking Represent sets of states and the transition relation as Boolean logic formulas Forward and backward fixpoints can be computed by iteratively manipulating these formulas –Forward, backward image: Existential variable elimination –Conjunction (intersection), disjunction (union) and negation (set difference), and equivalence check Use an efficient data structure for manipulation of Boolean logic formulas –BDDs

BDDs Efficient representation for boolean functions Disjunction, conjunction complexity: at most quadratic Negation complexity: constant Equivalence checking complexity: constant or linear Image computation complexity: can be exponential

Constraint-Based Verification Can we use linear arithmetic constraints as a symbolic representation? –Required functionality Disjunction, conjunction, negation, equivalence checking, existential variable elimination Advantages: –Arithmetic constraints can represent infinite sets –Heuristics based on arithmetic constraints can be used to accelerate fixpoint computations Widening, loop-closures

Linear Arithmetic Constraints Can be used to represent sets of valuations of unbounded integers Linear integer arithmetic formulas can be stored as a set of polyhedra c kl is a linear equality or inequality constraint and each where each c kl is a linear equality or inequality constraint and each is a polyhedron is a polyhedron

Linear Arithmetic Constraints Disjunction complexity: linear Conjunction complexity: quadratic Negation complexity: can be exponential –Because of the disjunctive representation Equivalence checking complexity: can be exponential –Uses existential variable elimination Image computation complexity: can be exponential –Uses existential variable elimination

A Linear Arithmetic Constraint Manipulator Omega Library [Pugh et al.] –Manipulates Presburger arithmetic formulas: First order theory of integers without multiplication –Equality and inequality constraints are not enough: Divisibility constraints are also needed Existential variable elimination in Omega Library: Extension of Fourier-Motzkin variable elimination to integers Eliminating one variable from a conjunction of constraints may double the number of constraints Integer variables complicate the problem even further

Fourier-Motzkin Variable Elimination Given two constraints   bz and az   we have a   abz  b  We can eliminate z as:  z. a   abz  b  if and only if a   b  Every upper and lower bound pair can generate a separate constraint, the number of constraints can double for each eliminated variable real shadow

Integers are More Complicated If z is integer  z. a   abz  b  if a  + (a - 1)(b - 1)  b  Remaining solutions can be characterized using periodicity constraints in the following form:  z.  + i = bz dark shadow

 y. 0  3y – x  7  1  x – 2y  5 Consider the constraints: 2x  6y2x  6y We get the following bounds for y: 6y  2x y  3x - 33x - 15  6y When we combine 2 lower bounds with 2 upper bounds we get four constraints: 0  14, 3  x, x  29, 0  12 Result is: 3  x  29

2y  x – 1 x – 5  2y 3y  x + 7 x  3y dark shadow real shadow 293 y x

How about Using BDDs for Encoding Arithmetic Constraints? Arithmetic constraints on bounded integer variables can be represented using BDDs Use a binary encoding –represent integer x as x 0 x 1 x 2... x k –where x 0, x 1, x 2,..., x k are binary variables You have to be careful about the variable ordering!

Arithmetic Constraints on Bounded Integer Variables BDDs and constraint representations are both applicable Which one is better?

smv: SMV smv+co: SMV with William Chan’s interleaved variable ordering omc: Our model checker built on Omega Library Intel Pentium PC (500MHz, 128MByte main memory) AG(!(pc1=cs && pc2=cs))

AG(cinchair>=cleave && bavail>=bbusy>=bdone && cinchair<=bavail && bbusy<=cinchair && cleave<=bdone)

AG(produced-consumed= size-available && 0<=available<=size)

Arithmetic Constraints vs. BDDs Constraint based verification can be more efficient than BDDs for integers with large domains BDD-based verification is more robust Constraint based approach does not scale well when there are boolean or enumerated variables in the specification Constraint based verification can be used to automatically verify infinite state systems –cannot be done using BDDs Price of infinity –CTL model checking becomes undecidable

Conservative Approximations p  ) p + ) p ) Compute a lower ( p  ) or an upper ( p + ) approximation to the truth set of the property ( p ) Model checker can give three answers: I p pppp “The property is satisfied” Ip pppp “I don’t know” “The property is false and here is a counter-example” Ip  p p p p sates which violate the property p+p+p+p+

Computing Upper and Lower Bounds Approximate fixpoint computations –Widening: To compute upper bound for least-fixpoints We use a generalization of the polyhedra widening operator by Cousot and Halbwachs –Collapsing (dual of widening): To compute lower bound for greatest-fixpoints –Truncated fixpoints: To compute lower bounds for least- fixpoints and upper bounds for greatest fixpoints Loop-closures –Compute transitive closure of self-loops –Can easily handle simple loops which increment or decrement a counter

Is There a Better Way? Each symbolic representation has its own deficiencies BDD’s cannot represent infinite sets Linear arithmetic constraint representations are expensive to manipulate –Mapping boolean variables to integers does not scale –Eliminating boolean variables by partitioning the state-space does not scale

Composite Model Checking Each variable type is mapped to a symbolic representation type –Map boolean and enumerated types to BDD representation –Map integer type to arithmetic constraint representation Use a disjunctive representation to combine symbolic representations Each disjunct is a conjunction of formulas represented by different symbolic representations

Composite Formulas Composite formula (CF): CF ::=CF  CF | CF  CF |  CF | BF | IF Boolean Formula (BF) BF ::=BF  BF | BF  BF |  BF | Term bool Term bool ::= id bool | true | false Integer Formula (IF) IF ::= IF  IF | IF  IF |  IF | Term int Rop Term int Term int ::= Term int Aop Term int |  Term int | id int | constant int where Rop denotes relational operators (=, , >, <, ,  ), Aop denotes arithmetic operators (+,-, and * with a constant)

Composite Representation Each composite formula A is represented as where –n is the number of composite atoms in A –t is the number of basic symbolic representations Sets of states and transitions are represented using this disjunctive representation Set operations and image computations are performed on this disjunctive representation

Conjunctive Decomposition Each composite atom is a conjunction Each conjunct corresponds to a different symbolic representation – x: integer; y: boolean; – x>0 and x’=x+1 and y´  y Conjunct x>0 and x´  x+1 will be represented by arithmetic constraints Conjunct y´  y will be represented by a BDD –Advantage: Image computations can be distributed over the conjunction (i.e., over different symbolic representations).

Composite Symbolic Library Our library implements this approach using an object- oriented design –A common interface is used for each symbolic representation –Easy to extend with new symbolic representations –Enables polymorphic verification –As a BDD library we use Colorado University Decision Diagram Package (CUDD) [Somenzi et al] –As an integer constraint manipulator we use Omega Library [Pugh et al]

Composite Symbolic Library: Class Diagram CUDD LibraryOMEGA Library Symbolic +intersect() +union() +complement() +isSatisfiable() +isSubset() +bacwardImage() +forwardImage() CompSym –representation: list of comAtom +intersect() + union() BoolSym –representation: BDD +intersect() +union() IntSym –representation: Polyhedra +intersect() +union() compAtom –atom: *Symbolic

Composite Symbolic Representation b’ x: integer, y:boolean (x>0 and x´  x+1 and y´=true) or (x<=0 and x´  x and y´  y) : CompSym representation : List : ListNode next :*ListNode data : compAtom 0 1 y´=true x>0 and x´=x y’=y x<=0 and x’=x

Satisfiability Checking boolean isSatisfiable(CompSym A) for each compAtom b in A do if b is satisfiable then return true return false boolean isSatisfiable(compAtom a) for each symbolic representation t do if a t is not satisfiable then return false return true is Satisfiable? isSatisfiable? false true  is Satisfiable? is Satisfiable? is Satisfiable? and

Backward Image: Composite Representation CompSym backwardImage(Compsym A, CompSym B) CompSym C; for each compAtom d in A do for each compAtom e in B do insert backwardImage(d,e) into C return C A: B: C:

Backward Image: Composite Atom compAtom backwardImage(compAtom a, compAtom b) for each symbolic representation type t do replace a t by backwardImage(a t, b t ) return a b: a:

Heuristics for Efficient Manipulation of Composite Representation Masking –Mask operations on integer arithmetic constraints with operations on BDDs Incremental subset check –Exploit the disjunctive structure by computing subset checks incrementally Merge image computation with the subset check in least-fixpoint computations Simplification –Reduce the number of disjuncts in the composite representation by iteratively merging matching disjuncts Cache expensive operations on arithmetic constraints

Simplification Example (y  z´ = z + 1)(x  z´ = z + 1)((x  y)  z´ > z)    ((y  x)  z´ = z + 1)   ((x  y)  (z´ = z + 1  z´ > z))  ((x  y)  z´ > z )

Polymorphic Verifier Symbolic TranSys::check(Node *f) { Symbolic s = check(f.left) case EX: s.backwardImage(transRelation) case EF: do snew = s sold = s snew.backwardImage(transRelation) s.union(snew) while not sold.isEqual(s) }  Action Language Verifier is polymorphic  When there are no integer variable in the specification it becomes a BDD based model checker

Bounded-Buffer Producer Consumer pstate=N && pstate´=1 && count<size && produced´=produced+1 && count´=count+1 cstate=N && cstate´=1 && count>0 && consumed´=consumed+1 && count´=count-1 1 N i 2 Producer N i 2 1 Consumer cstate=i && cstate´=i+1 && consumed´=consumed && count´=count pstate=i && pstate´=i+1 && produced´=produced && count´=count

Experiment CMC: Our composite model checker OMC: Our model checker built on Omega-library Partitioned: Control states are eliminated by partitioning the state space Mapped: Control states are mapped to integer variables SUN ULTRA 10 (768 Mbyte main memory)

Outline Model Checking Specification Language: Action Language –Synchronous vs. asynchronous composition –Translating hierarchical and tabular specifications to Action Language Verification Engine –Constraint-based verification –Composite Symbolic Library Applications –Synthesizing verified monitor classes –Verification of parameterized cache coherence protocols –Verification of workflow specifications Related, Current and Future Work

Synthesizing Verified Monitors [Yavuz-Kahveci, Bultan 01] Concurrent programming is difficult –Exponential increase in the number of states by the number of concurrent components Monitors provide scoping rules for concurrency –Variables of a monitor can only be accessed by monitor’s procedures –No two processes can be active in a monitor at the same time Java made programming using monitors a common problem

Monitors Challenges in monitor programming –Condition variables –Wait and signal operations Even with a few condition variables coordinating wait and signal operations can be difficult –Avoid deadlock –Avoid inefficiency due to unnecessary signaling

Monitor Specifications in Action Language Monitors with boolean, enumerated and integer variables Condition variables are not necessary in Action Language –Semantics of Action Language ensures that an action is executed when it is enabled We can automatically verify Action Language specifications We can automatically synthesize efficient monitor implementations from Action Language specifications

What About Arbitrary Number of Processes? Use counting abstraction [Delzanno CAV’00] –Create an integer variable for each local state of a process type –Each variable will count the number of processes in a particular state Local states of the process types have to be finite –Specify only the process behavior that relates to the correctness of the monitor –Shared variables of the monitor can be unbounded Counting abstraction can be automated

Readers-Writers Monitor Specification module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer() boolean writing; initial: !writing; wEnter: !writing and nr=0 and !busy and busy’ and writing’; wExit: writing and !writing’ and !busy’; Writer: wEnter | wExit; endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule

Readers-Writers Monitor Specification After Counting Abstraction module main() integer nr; boolean busy; parameterized integer numReader, numWriter; restrict: nr>=0 and numReader>=0 and numWriter>=0; initial: nr=0 and !busy; module Reader() integer readingF, readingT; initial: readingF=numReader and readingT=0; rEnter: readingF>0 and !busy and nr’=nr+1 and readingF’=readingF-1 and readingT’=readingT+1; rExit: readingT>0 and nr’=nr-1 readingT’=readingT-1 and readingF’=readingF+1; Reader: rEnter | rExit; endmodule module Writer()... endmodule main: Reader() | Writer(); spec: invariant([busy => nr=0]) endmodule

Verification of Readers-Writers Monitor IntegersBooleansCons. Time (secs.) Ver. Time (secs.) Memory (Mbytes) RW RW RW RW RW RW-P SUN ULTRA 10 (768 Mbyte main memory)

Synthesized Monitor Class: Uses Specific Notification Pattern public class ReadersWriters{ private int nr; private boolean busy; private Object rEnterCond, wEnterCond; private synchronized boolean Guard_rEnter() { if (!busy) { nr++; return true; } else return false; } public void rEnter() { synchronized(rEnterCond) { while(!Guard_rEnter()) rEnterCond.wait(); } public void rExit() { synchronized(this) { nr--; } synchronized(wEnterCond) { wEnterCond.notify(); } }... } All condition variables and wait and signal operations can be generated automatically

Verification of Parameterized Cache- Coherence Protocols [Delzanno, Bultan CP01] !grantS !inv: ex  ex’ nonex:  ex ?reqS ?reqE !!invS !invE:ex  ex’ nonex:  ex !grantE: ex’ Idle ServeSGrantS ServeEInvE GrantE ??invS ?grantS !reqS !reqE ?reqE Exclusive ?invE Null WaitSShared WaitE ?grantE SERVER CLIENT

Parameterized Protocol in Action Language module main() boolean ex; enumerated state {Idle, ServeE, InvE, GrantE, ServeS, GrantS}; integer xNull, xWaitS, xWaitE, xShared, xExclusive; initial: state=Idle and !ex and xNull>=1 and xShared=0 and xExclusive=0 and xWaitE=0 and xWaitS=0; restrict: xNull>=0 and xWaitS>=0 and xWaitE>=0 and xShared>=0 and xExclusive>=0 and n>=1; reqS: state=Idle && xNull>=1 && state'=ServeS && xNull'=xNull-1 && xWaitS'=xWaitS+1; reqE1: state=Idle && xNull>=1 && state'=ServeE && xNull'=xNull-1 && xWaitE'=xWaitE+1; reqE2: state=Idle && xShared>=1 && state'=ServeE && xShared'=xShared-1 && xWaitE'=xWaitE+1;... main: reqS | reqE1 | reqE2... endmodule 5 integer, 4 boolean variables

Experiments Two versions of the protocol –CCB: with broadcast –CCI: with invalidation loop Properties –P1-2: AG(  ((xShared  1  xExclusive  1)  xExclusive  2)) –P3: AG(xWaitS  1  AF(xShared  1)) –P4:  n, n  0, AG(xWaitS  n  AF(xS  n) –P5: AG(xWaitE  1  AF(xE  1))

Approx.Forward (iterations) Fixpoints (iterations) Time (secs.) Memory (Mbytes) CCB-P1-2EF(4) CCB-P1-2F(7)F(7),EF(1) CCB-P3EG(3),EF(5) CCB-P3F(7)EG(3),EF(1) CCB-P4EG(3),EF(8) CCB-P4F(7)EG(3),EF(1) CCB-P5YesEG(4),EF(11) CCB-P5YesF(7)EG(3),EF(1) CCI-P1-2EF(4) CCI-P1-2F(6)EF(1) CCI-P3YesEG(3),EF(5) CCI-P3F(6)EG(3),EF(1) CCI-P4  F(6)EG(3), EF(1) CCI-P5   SUN ULTRA 10 (768 Mbyte main memory)

Verification of Workflow Specifications [Fu, Bultan, Su, Hull 01] Workflow Languages –High-level languages for business applications –Programming for non-programmers Vortex Language –Module based –Source attributes, target attributes –Enabling conditions –Rules, combining policies –Declarative semantics –Acyclic dependency graph

Vortex Specifications Fast changing business logic   Rule based logic changes frequently   New rules added into system at any time   Error prone process Automated verification?

MIHU (May I Help yoU?)  Runs behind Web Server  Decides whether to launch the customer representative service

MIHU (May I Help yoU?) Source Attributes: Customer ID, Shopping cart, history logs Target Attribute: offer_AWD Integer variables: 40 Source lines: 800

Dependency Graph of MIHU

Experiments SMV translation required several heuristics to get it running SMV translation required several heuristics to get it running –Disjunctive transition BDD, variable pruning, initial image projection SMV version does not converge in 30hrs when we increase the integer widths to 16 bits SMV version does not converge in 30hrs when we increase the integer widths to 16 bits There are properties for which Action Language Verifier did not converge but SMV converged for  15 bits There are properties for which Action Language Verifier did not converge but SMV converged for  15 bits SMV gives a false negative for property P2 for 5 bits SMV gives a false negative for property P2 for 5 bits Both SMV and Action Language Verifier found an error for Property 3 Both SMV and Action Language Verifier found an error for Property 3 SMV(5bits)SMV(10bits)SMV(15bits)Action P112s 9MB16min 67MB2.6hrs 86MB10min 93MB P232s 12MB15min 66MB2.9hrs 86MB10min 93MB P319s 10MB18min 67MB2.3hrs 87MB27.7hrs 1GB SUN ULTRA 10 (768 Mbyte main memory)

Model Checking Software Specifications [Atlee, Gannon 93] Translating SCR mode transition tables to input language of explicit state model checker EMC [Clarke, Emerson, Sistla 86] [Chan et al. 98,00] Translating RSML specifications to input language of symbolic model checker SMV [McMillan 93] [Bharadwaj, Heitmeyer 99] Translating SCR specifications to Promela, input language of automata-theoretic explicit state model checker SPIN [Holzmann 97]

Specification Languages for Reactive Systems Specification languages for verification –[Milner 80] CCS –[Chandy and Misra 88] Unity –[Lamport 94] Temporal Logic of Actions (TLA) Specification languages for model checking –[Holzmann 98] Promela –[McMillan 93] SMV –[Alur and Henzinger 96, 99] Reactive Modules

Action Language TLA Connection [Lamport TOPLAS’94] Similarities: –Transition relation is defined using predicates on current (unprimed) and next state (primed) variables –Each predicate is defined using integer arithmetic, boolean logic, etc. Differences: In Action Language –Temporal operators are not used in defining the transition relation Dual language approach: temporal properties (in CTL) are redundant, they are used to check correctness –Synchronous and asynchronous composition operators are not equivalent to logical operators

Constraint-Based Verification: Not a New Idea [Cooper 71] Used a decision procedure for Presburger arithmetic to verify sequential programs represented in a block form [Cousot and Halbwachs 78] Used real arithmetic constraints to discover invariants of sequential programs

Constraint-Based Verification [Halbwachs 93] Constraint based delay analysis in synchronous programs [Halbwachs et al. 94] Verification of linear hybrid systems using constraint representations [Alur et al. 96] HyTech, a model checker for hybrid systems

Constraint-Based Verification [Boigelot and Wolper 94] Verification with periodic sets [Boigelot et al.] Meta-transitions [Delzanno and Podelski 99] Built a model checker using constraint logic programming framework [Boudet Comon], [Wolper and Boigelot ‘00] Translating linear arithmetic constraints to automata [Kukula et al. 98] Comparison of automata and constraint-based verification –no clear winner

Automata-Based Representations for Arithmetic Constraints [Klarlund et al.] MONA, an automata manipulation tool for verification [Boudet Comon] Translating linear arithmetic constraints to automata [Wolper and Boigelot ‘00] verification using automata as a symbolic representation [Kukula et al. 98] application of automata based verification to hardware verification

Combining Different Symbolic Representations [Chan et al. CAV’97] –both linear and non-linear constraints are mapped to BDDs –Only data-memoryless and data-invariant transitions are supported [Bharadwaj and Sims TACAS’00] –Combines automata based representations (for linear arithmetic constraints) with BDDs –Specialized for inductive invariant checking [Bensalem et al. 00] Symbolic Analysis Laboratory –Designed a specification language that allows integration of different verification tools

Current Work: New Symbolic Representations Integrating shape analysis to Composite Symbolic Library –[Sagiv et al.] Shape analysis: Used for verifying linked list implementations –Analyze monitor specifications with linked lists –Synthesizing concurrent data structures Integrating automata-based constraint representations to Composite Symbolic Library –[Kukula et al. 98] Comparison of automata and constraint- based verification

Future Work: To Abstract or not to Abstract Abstraction techniques –Restricting variable domains to finite sets –Predicate abstraction [Graf, Saidi 97, Saidi 00] When should we use abstraction and when should we use constraint-based techniques?

Concluding Thought The fates of specification languages and automated verification techniques are tied to each other One will not succeed without the other Goal: Developing verifiable specification languages