A generic approach for the automatic verification of featured, parameterised systems

1. A generic approach for the automatic verification of featured, parameterised systems Alice Miller and Muffy Calder University of Glasgow ICFI05

2. Model checking for FI analysis model up to 6 telephone components. 2 features, model check for FI Abstract model = finite no concrete comps (+features), and any no of unfeatured abstract components. Specific applications: POTS, email. What if abstract components have features? Can we make approach more generic (to extend to other applications?) ICFI05

3. Model checking (using SPIN) Kripke structure (FSA) property holds model (using Promela) Model check (using SPIN) system Buchi automaton Counterexample, modify system, model or property Specify property (using LTL) ICFI05

4. Model checking and FI Property based approach • If Mi is model representing n components where a component has feature fi, and Mj model where a component has feature fj (sim Mi,j) • if • Mi f1 but Mij  f1 then we have a FI ICFI05

5. Douglas Graham Induction/abstraction based approach • used for systems with regular topology (star, complete graph, ring, tree...) • Families of systems {Sn} where Sn is e.g. • system of nodes in star network executing tree identification • fully connected telephone network • peer to peer email system • pass the parcel with n players n=0 ICFI05

6. Families of systems Let Mn = M(p0 || p1 || p2 || … || pn-1) be a model of a system with n components – instances of a parameterised process We aim to reason about families of such systems Our goal n. M(p0 || p1 || p2 || … || pn-1) |= f Undecidable, in general! ICFI05

7. The general approach • Collect all components not indexed by property to be checked (abstract components) into single component, Abs • Modify remaining (concrete) components accordingly • Model check new model Theorem 1: If components satisfy certain restrictions, then if F holds for Mabsm then it holds for Mn for any nm supposef = f(0,1,…,m-1) Mn = M(p0 || p1 || p2 || … || pn-1) Mabsm = M(p1’ || p2’ || …pm-1’ || Abs) ICFI05

8. Need to extend to non-isomorphic components (i.e have features) • Then … ICFI05

9. The general approach applied to FI.. • If two features can be shown to not interact within finite (abstract) system of processes, then under certain restrictions they do not interact within a system of any size! Nb converse not true, but can usually find an interaction using the small finite model anyway. ICFI05

10. Simulation • Have to construct abstract model that simulates model of any size • Then if f holds for any path in abstract model, does so in original model ICFI05

11. Isomorphic abstract components • Abstract components have no features We have proved that Theorem 1 holds in this case e.g. Ryan et al LNCS 2975 Concrete Users Abstract Users (unbounded) Only concrete components may contain features Property indexed only by concrete component ids ICFI05

12. Concrete Users Abstract Users (unbounded) Latest results: non-isomorphic abstract components Theorem 1 holds for some features but not all. Requires classification of features as safe or unsafe. For our suite of features only one unsafe: RWF Abstract components may contain features Property indexed only by concrete component ids ICFI05

13. Our email model has some of these Classification of features Host owned, single index (HS) TCO, RBWF Host owned, double index (HD) OCS, ODS Partner owned, single index (PS) CFU, CFB, OCO Partner owned, double index (PD) TCS Third party owned, single index (TS) Third party owned, double index (TD) Multi-owned, single index (MS) RWF Theorem 1 holds provided abstract features are not multi-owned ICFI05

14. How did we prove this? • GC form • We assume that system specification can be expressed as infinite loop involving set of statements in guarded command form: do :: guard 1 command 1 :: guard 2  command 2 :: guard 3  command 3 :: etc. od Each guard contains a proposition regarding program counter (p_c), and each command includes a statement resetting p_c e.g. :: (p_c==2)x++; p_c++ ICFI05

15. This is a new bit! How did we prove this contd. • Prescribe way to convert finite model in GC form to abstract model in GC form so that transitions in finite model of any size matched in abstract model • Need to consider statements involving • communication • change of state of abstract components • features ICFI05

16. propositions re. global variables (e.g. channel contents) Is the feature subscribed to? Feature statements • Guard that can trigger a feature has the form (feature_prop)&&(localprop)&&(varprop) propositions re. local variables (e.g. p_c) (by self or partner) The classification of a feature determines nature of feature_prop and var_prop ICFI05

17. How did we prove this? contd. • If feature is host-owned we can simulate transitions from feature statements in abstract model as before. • In fact, this is always true • provided feature is not multiowned ICFI05

18. A generic approach • Provided system expressed in GC form where • statements must be open symmetric • ops on p-variables v restricted • features can be classified in this way • then approach applies to any featured system ICFI05

19. Conclusions • Have described generic approach to verify parameterised featured systems of any size Further work- • Apply induction/abstraction technique to other domains ICFI05