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

2. 28/6/05ICFI052 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?)

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

4. 28/6/05ICFI054 Model checking and FI Property based approach If M i is model representing n components where a component has feature f i, and M j model where a component has feature f j (sim M i,j ) if M i   1 but M ij   1 then we have a FI

5. 28/6/05ICFI055 Induction/abstraction based approach used for systems with regular topology (star, complete graph, ring, tree...) Families of systems {S n } where S n 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 Douglas Graham  n=0

6. 28/6/05ICFI056 Families of systems We aim to reason about families of such systems Let M n = M(p 0 || p 1 || p 2 || … || p n-1 ) be a model of a system with n components – instances of a parameterised process Our goal  n. M(p 0 || p 1 || p 2 || … || p n-1 ) |=  Undecidable, in general!

7. 28/6/05ICFI057 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 M n = M(p 0 || p 1 || p 2 || … || p n-1 ) M abs m = M(p 1 ’ || p 2 ’ || …p m-1 ’ || Abs) suppose  =  (0,1,…,m-1) Theorem 1: If components satisfy certain restrictions, then if  holds for M abs m then it holds for M n for any n  m

8. 28/6/05ICFI058 Need to extend to non-isomorphic components (i.e have features) Then …

9. 28/6/05ICFI059 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.

10. 28/6/05ICFI0510 Simulation Have to construct abstract model that simulates model of any size Then if  holds for any path in abstract model, does so in original model

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

12. 28/6/05ICFI0512 Latest results: non-isomorphic abstract components Concrete Users Abstract Users (unbounded) Abstract components may contain features Property indexed only by concrete component ids 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

13. 28/6/05ICFI0513 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 Our email model has some of these

14. 28/6/05ICFI0514 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++

15. 28/6/05ICFI0515 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 This is a new bit!

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

17. 28/6/05ICFI0517 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

18. 28/6/05ICFI0518 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

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