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

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?)
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)
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

5
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

?n0
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!
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
suppose f f(0,1,,m-1)
Mn M(p0 p1 p2 pn-1)
Mabsm M(p1 p2 pm-1 Abs)
8

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

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

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
12
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
13
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
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_c2)??x p_c
15
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

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

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

19
Conclusions

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