ICFEM98, Brisbane Australia, 11 Decemb er 1998, 9am - PowerPoint PPT Presentation

ICFEM98, Brisbane Australia, 11 Decemb er 1998, 9am

Ubiquitous Abstraction: A New App roach T o Mechanized F o rmal V eri�cation John Rushb y Computer Science Lab o rato ry SRI International Menlo P a rk, CA John Rushb y , SRI Ubiquitous Abstraction: 1

F o rmal Metho ds and Calculation � F o rmal metho ds contribute useful mental framew o rks, notations, and systematic metho ds to the design, do cumentation, and analysis of computer systems � But the singula r b ene�t from sp eci�cally fo rmal metho ds is that they allo w certain questions ab out a soft w a re o r ha rdw a re design to b e answ ered b y symb olic calculation (e.g., fo rmal deduction, mo del checking) � And those calculations can b e automated fo r sp eed, reliabilit y , rep eatabilit y � Calculations can b e used fo r debugging (refutation) and design explo ration as w ell as p ost-ho c veri�cation � Augments simulation, p rotot yping, testing � Compa rable to the w a y mathematics is used in other engineering disciplines John Rushb y , SRI Ubiquitous Abstraction: 2

Automating F o rmal Calculations � T o ols a re not the most imp o rtant thing ab out fo rmal metho ds � They a re the only imp o rtant thing � Just lik e any other engineering calculations, it's to ols that mak e fo rmal calculations feasible and useful in p ractice � And the imp o rtant things ab out to ols a re � Sp eed, scaling, automation, p o w er � Sp eed, scaling, automation, p o w er � Sp eed, scaling, automation, p o w er � Oh, and soundness John Rushb y , SRI Ubiquitous Abstraction: 3

Where T o Apply F o rmal Metho ds T o ols? � There is little p oint in applying fo rmal metho ds to topics that a re handled adequately b y traditional metho ds � E.g., re�nement to co de; veri�cation of co de (Except in regulated industries; even there, cost is critical) � F o cus on where the intractable di�culties a re � Usually in the ha rdest elements of design � Concurrency, real time, fault tolerance Seconda ry advantage: these elements a re usually small, have the b est p eople � And where the greatest costs a re incurred � Erro rs intro duced in the ea rly lifecycle � Notably , omissions in requirements John Rushb y , SRI Ubiquitous Abstraction: 4

So What Should T o ols Do? � Determine whether sp eci�cations of complex, often incomplete, designs have certain desired p rop erties � Prop erties often amount to less than full co rrectness � Can lo ok at this from t w o sides Refutation: try and �nd bugs � Need not b e sound (�nds all erro rs) o r complete (�nds only real erro rs) � As long as it �nds enough real bugs to b e cost-e�ective � Should p rovide diagnostic info rmation (counterexample) V eri�cation: try and sho w \co rrectness" � Generally mo re di�cult than refutation � And less helpful when bugs a re p resent � Switch to veri�cation when refutation runs out of steam John Rushb y , SRI Ubiquitous Abstraction: 5

Mechanizing Refutation: Mo del Checking � If design has a �nite state space, can often check p rop erties b y mo del checking � Check whether design is a Kripk e mo del of p rop ert y exp ressed as a temp o ral logic fo rmula Name often used fo r all related metho ds � Complexit y is linea r in numb er of states � But that gro ws as p ro duct of size of data structures, and is exp onential in numb er of interacting comp onents � Hence, must construct abstracted o r do wnscaled mo dels � Do wnscaling is aggressive (unsound) abstraction � Exp erience is that y ou lea rn mo re b y examining all p ossibilities of do wnscaled mo del than b y p robing some of the p ossibilities of the full thing (as b y simulation o r testing) John Rushb y , SRI Ubiquitous Abstraction: 6

Mechanizing F o rmal V eri�cation � The to ols a re generally based on interactive theo rem p roving � With substantial automation ? Decision p ro cedures, rewriting, heuristics, lib ra ries � Guiding the interaction requires skill, but � In domains with decision p ro cedures o r go o d lib ra ries � And sp eci�cations a re functional � It is often no ha rder than hand p ro of (of compa rable detail) � But fo r concurrent and distributed systems � Where sp eci�cations a re transition relations � It is very ha rd indeed ? Not due to lack of theo rem p roving p o w er ? But to the di�cult y of inventing strong inva riants John Rushb y , SRI Ubiquitous Abstraction: 7

A T rivial Example Sho w that when control is at B, then x � 2 x := x+1 x := 2 x := x+1 A B x � 3 ! x := x-2 John Rushb y , SRI Ubiquitous Abstraction: 8

A ttempted Pro of � W e'll use the induction scheme: ( 8 s: init(s) � p(s)) ^ ( 8 pre, post: p(pre) ^ tr(pre, post) � p(post)) � invariant(p)(init , tr) Whose o wn p ro of in PVS is (SKOSIMP) (EXPAND "invariant") (INDUCT-AND-SIMP LI FY "j") � The p ro of steps (USE "ind[state]") (GROUND) ("1" (GRIND)) ("2" (GRIND)) Yield [-1] pc(pre!1) = A [-2] pc(post!1) = B [-3] x(pre!1) = 0 |------- [1] x ( pre ! 1 ) + 1 � 2 � Need to strengthen inva riant: x � 1 when control at A John Rushb y , SRI Ubiquitous Abstraction: 9

And In General? � Can extract terms that need to b e added (conjoined) to the inva riant b y examining these failed subgoals (Simila r ideas fo r lo op inva riants go back 20 y ea rs) � La rger example: veri�cation of Bounded Retransmission Proto col (BRP) � Required 57 strengthenings � E�o rt required generally defeats all but the most determined � The case explosion p roblem � Everything is p ossible but nothing is easy � There is much w o rk on metho dologies fo r deriving suitable inva riants systematically (fo r given classes of p roblems) � But w e're lo oking fo r general metho ds. . . John Rushb y , SRI Ubiquitous Abstraction: 10

Another Direction � Mo del checking avoids all this hassle (b y calculating a �xp oint) � Substitutes calculation fo r p ro of � But only w o rks fo r �nite-state systems � So let's create a �nite-state abstraction (i.e., app ro ximation) � And mo del-check that � Will also need to p rove that the abstraction is p rop ert y-p reserving John Rushb y , SRI Ubiquitous Abstraction: 11

V eri�cation Via Prop ert y-Preserving Abstraction � In general, w e need a (�nite) abstract state space with transition relation tr a � And an abstraction function abs from the concrete state space to the abstract one � And a p redicate p on the abstract states a � Such that 1. init ( cs ) � init ( abs ( cs )) c a 2. tr ( pre ; post ) � tr ( abs ( pre ) ; abs ( post )) c c c a c c 3. p ( abs ( cs )) � p ( cs ) a c � Then � invariant ( p )( init ; tr ) � invariant ( p )( init ; tr ) a a a c c c � And the antecedent can b e p roved b y mo del checking John Rushb y , SRI Ubiquitous Abstraction: 12

The Example: Bo olean Abstraction � Often convenient to cho ose an abstract state space consisting of � The control lo cations of the concrete system, plus � Some b o olean state va riables that co rresp ond to p redicates in the concrete system � This is Bo olean abstraction � F o r the example, w e'll have one abstract Bo olean state va riable co rresp onding to the concrete state p redicate x � 2 John Rushb y , SRI Ubiquitous Abstraction: 13

An Abstract T ransition Relation F o r The Example A B x � 2 x � 2 A x 6� 2 Clea rly , the abstract inva riant is satis�ed John Rushb y , SRI Ubiquitous Abstraction: 14

V eri�cation Conditions fo r the Example Abstraction � All trivial except numb er 2: default p ro of strategy yields [-1] pc ( post ! 1 ) = B c [-2] x ( pre ! 1 ) = 0 c |------- [1] x ( pre ! 1 ) + 1 � 2 c � Essentially the same as in the basic inva riance p ro of � Requires an inva riant! � La rger example: veri�cation of Bounded Retransmission Proto col (BRP) b y abstraction � Required 45 inva riants John Rushb y , SRI Ubiquitous Abstraction: 15