1 / 18

Deductive tools in insertion modeling verification A.Letichevsky

Deductive tools in insertion modeling verification A.Letichevsky. INTAS Moscow 27-29 August 2007. August 27-29 2007. August 27-29 2007. Moscow meeting. Moscow meeting. 1. 1. 1. Content. New results in semantics of BPSL. Specification languages Static requirements checking

sai
Download Presentation

Deductive tools in insertion modeling verification A.Letichevsky

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deductive tools in insertion modeling verificationA.Letichevsky INTAS Moscow 27-29 August 2007 August 27-29 2007 August 27-29 2007 Moscow meeting Moscow meeting Moscow meeting 1 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 August 27-29 2007 Moscow meeting Moscow meeting Moscow meeting 2 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 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 August 27-29 2007 Moscow meeting Moscow meeting Moscow meeting 4 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 τ 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 August 27-29 2007 Moscow meeting Moscow meeting Moscow meeting 5 5

  6. Phone n Phone m Network Phone n Network phone(m,dial) phone(n,idle) dial(m,n) offhook n dialtone n phone(m, dial n) phone(n, dial) call setup initial call setup dialing 1 Basic protocol is a process with pre- and postconditions Precondition Postcondition August 27-29 2007 August 27-29 2007 Moscow meeting Moscow meeting Moscow meeting 6 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 Postconditions: 1-st order formula as in precondition Assignments x:=y considered as statements x´=y Updating lists August 27-29 2007 Moscow meeting Moscow meeting 7

  8. Defined by the notion of implementation: Attributed transition system with validity relation s|=α ,… such that for each BP and its instantiation (direct implementation) (inverse implementation) For each finite MSC Csuch that (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. Semantics of BPSL August 27-29 2007 Moscow meeting Moscow meeting 8

  9. Canonical form of behaviors Partially sequential composition Moscow meeting

  10. Some results on abstractions A class of concrete implementationsConcr(P) is defined and proved to be direct and inverse implementationsof consistent BPS P. Two classesAdir(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). Moscow meeting

  11. Abstraction relation on states Attributed transition systems with the same attribute labeling and validity more abstract: Moscow meeting

  12. direct a s' t' a s' t' inverse a s a t s t Abstraction relation on systems Preserve initial states Moscow meeting

  13. Predicate transformers for abstract implementations State and precondition were valid before Only attributes in precondition can change values Postcondition with assignments Moscow meeting

  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 Moscow meeting

  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 Moscow meeting

  16. Inductive proving of safety safety and precondition were valid before Safety will be valid after Moscow meeting

  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 Moscow meeting

  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.) Moscow meeting

More Related