1 / 88

Tools for Specification, Verification, and Synthesis of Reactive Systems

Tools for Specification, Verification, and Synthesis of Reactive Systems. Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan/ http://www.cs.ucsb.edu/~bultan/composite/. Action Language Verifier.

liam
Download Presentation

Tools for Specification, Verification, and Synthesis of Reactive Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Tools for Specification, Verification, and Synthesis of Reactive Systems Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan/ http://www.cs.ucsb.edu/~bultan/composite/

  2. Action Language Verifier Composite Symbolic Library Tools for Specification, Verification, and Synthesis of Reactive Systems Action Language specification Action Language Parser Code Generator Omega Library CUDD Package Verified code

  3. 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

  4. Composite Symbolic Library[Yavuz-Kahveci, Tuncer, Bultan TACAS01, FROCOS02] • 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

  5. 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

  6. 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, 02] • 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 TACAS01]

  7. 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 • Synthesizing Verified Monitors • Airport Ground Traffic Control case study • Related, Current and Future Work

  8. 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

  9. 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

  10. 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

  11. 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’

  12. 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

  13. S :Cartesian product of variable domains defines the set of states A Closer Look I : Predicates defining the initial states 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 R : Atomic actions of the 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

  14. 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);

  15. 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

  16. 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;

  17. 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 and i’ = i + 1 or i >= max & i’ = i) and (j < max & j’ = j + 1 or j >= max & j’ = j);

  18. 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

  19. 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

  20. Statecharts to Action Language Alarm 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 Shut t1 t2 Op t3 Mode Vol On 1 t4 t5 t6 t7 Off 2 Preserves the structure of the Statecharts specification

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

  22. 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 the transition relations of the tables

  23. 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 Heater AC

  24. 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 • Synthesizing Verified Monitors • Airport Ground Traffic Control case study • Related, Current and Future Work

  25. Model Checking Given a program and a temporal propertyp: • Either show that all the initial states satisfy the temporal propertyp • set of initial states  truth set of p • Or find an initial state which does not satisfy the propertyp • a state  set of initial states  truth set of p • and generate a counter-example starting from that state

  26. Temporal Properties  Fixpoints backwardImage of p Backward fixpoint Initial states • • • p initial states that violate Invariant(p) states that can reach p i.e., states that violate Invariant(p) Invariant(p) Forward fixpoint Initial states • • • p reachable states that violate p forward image of initial states reachable states of the system

  27. 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

  28. 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

  29. 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

  30. 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 where each cklis a linear equality or inequality constraint and each is a polyhedron

  31. 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

  32. 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 • Can be handled using divisibility constraints

  33. 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 x0x1x2... xk • where x0, x1, x2, ... , xk are binary variables • You have to be careful about the variable ordering!

  34. Arithmetic Constraints on Bounded Integer Variables • BDDs and constraint representations are both applicable • Which one is better? • A case study: Verification of Workflow Specifications

  35. 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

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

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

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

  39. Dependency Graph of MIHU

  40. Experiments SUN ULTRA 10 (768 Mbyte main memory) • 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 • 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 • Both SMV and Action Language Verifier found an error for Property 3

  41. 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

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

  43. 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

  44. 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

  45. 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

  46. Composite Formulas Composite formula (CF): CF ::=CF CF | CFCF | CF | BF | IF Boolean Formula (BF) BF ::=BFBF | BFBF | BF | Termbool Termbool ::= idbool | true | false Integer Formula (IF) IF ::= IFIF | IFIF | IF | TermintRopTermint Termint ::= TermintAopTermint | Termint | idint | constantint where Rop denotes relational operators (=, , > , <, , ), Aop denotes arithmetic operators (+,-, and * with a constant)

  47. Composite Representation Each composite formula A is represented as where • n is the number of composite atoms in A • tis 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

  48. 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+1andy´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).

  49. 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]

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

More Related