INTAS Moscow
27-29 August 2007
Deductive tools in insertion modeling
verification
A.Letichevsky
August 27-29 2007
Moscow meeting
1
Content
1. Specification languages
2. Static requirements checking
3. Trace generation
New results in semantics of
BPSL
New results in tools
development
New predicate
transformers for inductive
proving
August 27-29 2007
Moscow meeting
Insertion modeling:
Cybernetics and system Analyses
4, 2005 (Specification of systems
by means of basic protocols)
2
Specification languages
• Basic Protocol Specification Language (BPSL) is
the main SL of insertion modeling
• Other languages used for industrial projects
– UML
– SDL
– MSC
• Translation to BPSL (presentation of S.Potienko)
• Process language semantics
August 27-29 2007
Moscow meeting
3
Basic Protocol Specifications
Environment description (structural requirements)
Defines the signature and axioms of Basic Language,
(first order logic language used for the description of local properties of a system)
environment, and agent attributes
The set of Basic Protocols (local requirements)
Define the transitions of environment with inserted agents
Global requirements
Define the properties of a system in terms of temporal logic
(mostly safety and liveness)
August 27-29 2007
Moscow meeting
4
Environment description
Types:
Data types
simple: int, real, Bool, intervals, enumerated, symbolic (free terms), agent
behaviors (process algebra), ADT
lists: list (m) of τ
object types: obj(a1 :1 , a2 : 2 ,...)
functional: ( 1 , 2 ,...)   (arrays are considered as functional types)
Agent types:
defined by the set of typed agent attributes
Environment attributes:
used as functional symbols (simple, lists, and objects = arity 0)
Agent attributes: typed names
Instances: (for MSC as processes in BPs)
Axioms: formulas without attributes (ADT)
Rewriting rule systems: equations as in APS (ADT and normal forms)
Initial states: formula of basic language or concrete state
August 27-29 2007
Moscow meeting
5
Basic protocol is a process with pre- and postconditions
Phone n
Network
phone(n,idle)
offhook n
dialtone n
Phone m
Network
Phone n
phone(m,dial)
dial(m,n)
Precondition
Postcondition
phone(m, dial n)
phone(n, dial)
call setup initial
August 27-29 2007
call setup dialing 1
Moscow meeting
6
Basic protocols
Algebraic representation:
Forall x( ( x)  P( x)   ( x))
x – list of typed parameters, P – process,  (x ) and  (x) are pre- and postconditions.
Preconditions:
1-st order formula with the following literals:
State assumptions (like phone(m, idle))
Linear inequalities for numeric
Equalities for symbolic
Boolean attribute expressions
Postconditions:
1-st order formula as in precondition
Assignments x:=y considered as statements x´=y
Updating lists
August 27-29 2007
Moscow meeting
7
Semantics of BPSL
Defined by the notion of implementation:
Attributed transition system with validity relation s|=α ,…
such that for each BP Forall x( ( x)  P( x)   ( x)) and its
instantiation B  P (t )
B ][ C ]
s |  , s [
 s  s | 
B ][ C ]
(s |  ), s [
 s  s | 
(direct implementation)
(inverse implementation)
For each finite MSC C such that [ B]  [C ] (permutability relation on actions
and partially sequential composition of processes).
Concrete implementations: interpretation of signature and initial states are
fixed as well as deterministic transitions, validity is computed from attribute
valuations.
Abstract implementations: interpretation of signature and initial states are not
fixed, validity is inferenced from the states labeling.
August 27-29 2007
Moscow meeting
8
Partially sequential composition
u   ai .u i   u , v   b j .v j   v
iI
Canonical form of behaviors
jJ
u  v   ai .(ui  v) 
iI
b .(u  v )  ( ; )
j
u  b j , j J
j
u
v
(;  )   , (;  ) , (0;  )  0
(( :  );  )   : ( ;  )
August 27-29 2007
Moscow meeting
9
Some results on abstractions
A class of concrete implementations Concr(P) is defined and proved
to be direct and inverse implementations of consistent BPS P.
Two classes Adir(P) and Ainv(P) of direct and inverse abstract
implementations has been defined and proved to be implementations of
consistent BPS P.
Each abstract implementation is an abstraction of some concrete
one.
There exist the most abstract implementation (is an abstraction of
all concrete implementations).
August 27-29 2007
Moscow meeting
10
Abstraction relation on
states
Attributed transition
systems with the
same attribute
labeling and validity
Abs  S  S 
( s, s)  Abs  (  BL)(( s |  )  ( s |  ))
more abstract: s  s
August 27-29 2007
Moscow meeting
11
Abstraction relation on systems
1
 dir ,  inv




Abs
S S :
Preserve initial states

s'
s
a
a
t'

t
direct

inverse
s'
s
a
a
t'

t
a
a
( s  S , s   S )(( s , s)    s  

t   (t  S )( s 

t  (t , t )   ))
( s  S , s   S )(( s , s)    s   t   (t  S )( s  t  (t , t )   ))
a
a
( s  S , s   S )( s  s   s 

t  (t   S )( s  

t   t  t ))
( s  S , s   S )( s  s   s  t  (t   S )( s   t   t  t ))
August 27-29 2007
Moscow meeting
12
Predicate transformers
for abstract implementations
  B  
[B]
 
 ,     ,    pt ( ,  )
pt ( (r , s),  (r ))  u ( (u, s)   (u, s))   (r )
State and precondition were
valid before
Only attributes in precondition
can change values
pt ( ( p, q, r ), ( p1 : t1 ( p, q, r )) & ... & ( pm : tm ( p, q, r )) &  ( p, q)) 
(u, v)( (u, v, r ) & ( p1  t1 (u, v, r )) & ... & ( pm  t m (u, v, r ))) &  ( p, q)   ( p, q, r )
Postcondition with
assignments
August 27-29 2007
Moscow meeting
13
The applications of BPSL
Formalizing requirements
Experience in Telecommunications,
Telematics and other application domains
(projects for Motorola)
Formal description of MPI library
(projects for Intel)
Tools for
static and dynamic
requirements checking
VRS
Verification of Requirement
Specifications
a tool developed
for Motorola
Generating tests from requirement specifications
August 27-29 2007
Moscow meeting
14
Static requirements
checking
Disjunction of preconditions is valid
• Proving consistency and completeness
• Proving safety
• Computing invariants
Preconditions for BPs (with the
same external actions) must not
intersect
August 27-29 2007
Moscow meeting
15
Inductive proving of safety
Forall x( ( x)  P( x)   ( x))
xpt ( (r , s )   ( x, r , s ),  ( x, r ))   (r , s )
xu ( (u , s )   ( x, u, s )   ( x, r ))   (r , s )
safety and precondition
were valid before
August 27-29 2007
Safety will be valid after
Moscow meeting
16
Dynamic requirements checking
• Concrete trace generator
– Generating traces and checking properties for concrete
models
• Symbolic trace generator
– Generating traces and checking properties for abstract
models
• Checking safety and reachability
• Generating tests for given coverage criteria
More details in presentation
of Letichevsky Jr
August 27-29 2007
Moscow meeting
17
Symbolic trace generation
• Checking applicability of protocol
– Satisfiability of current state and precondition
– Proving existential formula
• Computing predicate transformer
– Proving predicate transformer formula
• Combining numeric and symbolic
constraints
• Using data structures (arrays, lists etc.)
August 27-29 2007
Moscow meeting
18