Deductive tools in insertion modeling verification A.Letichevsky

1
Deductive tools in insertion modeling
verificationA.Letichevsky
INTAS Moscow 27-29 August 2007
August 27-29 2007
Moscow meeting
1
August 27-29 2007
Moscow meeting
1
1
2
Content
New results in semantics of BPSL

• Specification languages
• Static requirements checking
• Trace generation

New results in tools development
New predicate transformers for inductive proving
Insertion modeling Cybernetics and system
Analyses 4, 2005 (Specification of systems by
means of basic protocols)
August 27-29 2007
Moscow meeting
2
August 27-29 2007
Moscow meeting
2
3
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
4
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
August 27-29 2007
Moscow meeting
4
4
5
Environment description
Types Data types simple int, real, Bool,
intervals, enumerated, symbolic (free terms),
agent behaviors (process algebra), ADT lists
list (m) of t object types functional
(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
August 27-29 2007
Moscow meeting
5
6
Basic protocol is a process with pre- and
postconditions
Precondition
Postcondition
August 27-29 2007
Moscow meeting
6
August 27-29 2007
Moscow meeting
6
6
6
7
Basic protocols
Algebraic representation x list of typed
parameters, P process, and
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 Postcondit
ions 1-st order formula as in precondition
Assignments xy considered as statements xy
Updating lists
August 27-29 2007
Moscow meeting
7
8
Semantics of BPSL
August 27-29 2007
Moscow meeting
8
9
Partially sequential composition
10
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).


11
Abstraction relation on states
Attributed transition systems with the same
attribute labeling and validity
more abstract
12
Abstraction relation on systems
Preserve initial states
13
Predicate transformers for abstract
implementations
State and precondition were valid before
Only attributes in precondition can change values
Postcondition with assignments
14
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)
VRS Verification of Requirement
Specifications a tool developed for Motorola
Tools for static and dynamic requirements
checking
Generating tests from requirement specifications
15
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
16
Inductive proving of safety
safety and precondition were valid before
Safety will be valid after
17
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
18
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.)