An Introduction to CSP B http:www'cspb'org

1
An Introduction to CSP Bhttp//www.csp-b.org

• Neil Evans, AWE, UK
• Helen Treharne, Steve Schneider University of
  Surrey

2
Aim of Tutorial

• To introduce our CSP B approach
• To persuade you that CSP B is a natural
  technique for systems modelling
• By the end of the tutorial you will have
• developed an understanding of the responsibility
  of the CSP part and the B part of a specification
• understood through examples that it is an
  iterative specification and refinement process

3
Overview of Tutorial

• What is CSP B ?
• Introducing single components
• Proving consistency
• Introducing multiple components
• Proving consistency revisited
• Case Studies describe overall CSPB
  specification and what we can prove about them
• Bounded Retransmission Protocol
• Platelet modelling

4
What is CSB B ?
5
Event vs State

• CSP for analysing control aspects
• Hoare 1985
• Multos (secure smart card operating system) 2000
• FDR 1989
• B for analysing operations on state
• Abrial 1991
• Line 14 Paris Metro 1998
• BToolkit 1993

6
What makes CSP B novel?

• CSP and Object-Z (Smith/Derrick 1997)
• CSP B (Schneider/Treharne 1999, 2000)
• Retains original semantics of CSP and B
• Morgans CSP semantics of action systems provides
  a formal link between the two worlds (1990)
• Clear separation of views
• Enables use of existing tools
• CSP2B (Butler 2000)
• Circus Z CSP (Woodcock/Cavalcanti 2002)
• Event B- (Abrial 1996 and RODIN Project 2005)

7
Example B machine

• A B machine is the main construct used in B
  specifications
• It is object-like because it encapsulates state
  and operations
• Its interface are the operations it provides
• State consist of a set of variables that are
  constrained by the machines invariant
• Operations can accept input, change the state,
  and query the state

8
B Operations

• Partial or fragile operations have preconditions
• A precondition is an assumption that the caller
  of the operation needs to makes sure that it
  holds
• Cannot guarantee an operations behaviour if
  called outside its precondition
• Example floor gt 0 in dec
• Total or robust operations
• Always safe to call these operations
• Example isZero
• All our operations are non-blocking, can always
  be called but may not always be safe to do so

9
Sequences of B operations

• Consider the Lift machine in its initial state
• is a valid sequence
• is not a valid sequence
• is not a valid sequence
• is a valid sequence
• We characterise all sequences of operations as
  traces
• We characterise invalid sequences of operations
  as divergences

10
How to control B machines?

• CSP used to control flow of operation calls
• Define a controlled component
• Parallel combination of a controller and a B
  machine
• Justified because both CSP and B have process
  semantics
• Use CSP events to match B operations
  calls

P
M
11
Example Lift Component
up.3
up
down
ground

• External channels accept input or communications
• B operations are called to set the state of the
  lift appropriately

LiftCtrl
inc
dec
inc.3
isZero
Lift
3
0
12
Example Lift Component
13
Controller language

• The CSP controller language for driving a B
  machine is sequential one thing follows another.
  It includes (among others)
• Input and output on an external channel
• Input and output on a machine channel
• choice
• conditional expression
• parameterised recursive call

14
Consistency of a single component

• Why do we want it?
• We must make sure that a controller calls all the
  operations of the B machine within their
  preconditions - divergence-free component
• How do we demonstrate it?
• Ideally in practice, using ProB
• How do we justify it?
• Proved using wp semantics

15
Summary

• CSPB Development Steps covered so far
• Develop the B components and verify state
  properties
• Develop each component pair
• Verify divergence freedom of each pair

16
Experiments with ProB

17
Process/Machine pair
CSP output value cycles between 0 and 3
18
What does consistency mean?

• Initialisation of M does not refer to the control
  variables but CLI may dependent of the initial
  state of the parameters of the mutual
  recursion.
• We need to find a control loop invariant, CLI
  which need not necessarily hold after each
  individual OPERATION but must hold at the end of
  every pass through the loop.
• Translate every process equation separately using
  rules

19
Representing the CLI and example in ProB

• Add an operation to simulate providing the right
  range of values
• Embed the CLI predicate inside two special
  operations
• In Proc the CLI predicate is simply true
• Value of nn represented the control points
• Use set_up to configure the state to meet the CLI
• update checks that the CLI is re-established

20
Proof of Consistency

• Each process body is translated into an
  equivalent sequence of B operations
• A control loop invariant (CLI) is constructed so
  that
• It is established after initialisation
• Each (translated) process body maintains the
  invariant

21
Example with no parameters

• Two coins are input
• User can choose either a chocolate or biscuit -
  their B operations have the same behaviour
• Is this a consistent component?

22
Proving Consistency

• At the end of each pass through the VM loop
  and is an appropriate
• We use the following translation rules
• We prove using wp semantics

23
Proof of Consistency(revisited)

• When we have mutually recursive processes and
  input and output communication we need more
  complex proof conditions
• The environment binding allows us to track
  values

24
Importance of Initialisation Condition

• Consider the process
• where the B operation reset is defined as
• and the initialisation

• CLI is
• The CLI proof boils down to
• However the initialisation condition is not met