1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 3. Specification Automata Syntax, given a set A of atomic observations: Sfinite set of states S 0 Sset of initial states S S transition.
Advertisements

Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Model Checking and Testing combined
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
M ODEL CHECKING -Vasvi Kakkad University of Sydney.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Formal verification in SPIN Karthikeyan Bhargavan, Davor Obradovic CIS573, Fall 1999.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
S. Ramesh Model-Checking Distributed Software S. Ramesh IIT Bombay.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Digitaalsüsteemide verifitseerimise kursus1 Formal verification: Property checking Property checking.
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Temporal Logic and Model Checking. Reactive Systems We often classify systems into two types: Transformational: functions from inputs available at the.
Witness and Counterexample Li Tan Oct. 15, 2002.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Review of the automata-theoretic approach to model-checking.
1 Completeness and Complexity of Bounded Model Checking.
Witness and Counterexample Li Tan Oct. 15, 2002.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
LTL – model checking Jonas Kongslund Peter Mechlenborg Christian Plesner Kristian Støvring Sørensen.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
Model Checking and Related Techniques
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
15-820A 1 LTL to Büchi Automata Flavio Lerda A 2 LTL to Büchi Automata LTL Formulas Subset of CTL* –Distinct from CTL AFG p  LTL  f  CTL. f.
Wishnu Prasetya Model Checking with SPIN A Bit More about SPIN.
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Temporal Logic Model-checking with SPIN
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
May University of Glasgow Generalising Feature Interactions in Muffy Calder, Alice Miller Dept. of Computing Science University of Glasgow.
Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation.
VIS Technology Transfer Course Session 7 Fairness Constraints and Monitors Serdar Tasiran.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Today’s Agenda  Quiz 5 (end of the class)  Quick Review  Finish Search Algorithms Formal Methods in Software Engineering1.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
15-820A 1 LTL Model Checking A Flavio Lerda.
Formal verification in SPIN
Automatic Verification
Formal Methods in software development
An explicit state model checker
Formal Methods in software development
Presentation transcript:

1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for proctype, with one exception. Every statement in a temporal (never) claim must model a proposition and must be side-effect free. A never claim expresses behaviour that is claimed to be impossible. There can be only one never claim per model. E.g. #define p = (x>=4) never { T0: if :: (true) -> goto T0 :: (p) -> goto T1 T1: skip }

2 Matching Claims The temporal claim and the model (under examination) are executed in lock-step. The temporal claim cannot alter the model behaviour. The first statement (ie proposition) of the temporal claim labels the first reachable state of the combined model (after the init process has been executed). Thereafter, for every reachable system state, the executability of the corresponding proposition of the temporal claim must be evaluated. Each such proposition (statement) can be executable or not- executable. if it is executable then the proposition is true and the temporal claim is moved on to its next statement, if it is not executable then the proposition is false. This means that the behaviour described by the current execution path cannot be matched by the claim. The search will continue along other paths.

3 Matching Claims A temporal claim is matched when: it reaches its normal end-state, i.e. }. This is the case for finite executions. In this case all the propositions held in each step of a computation path. A correctness violation has occurred. (A so-called never behaviour actually occurred.) an acceptance cycle is detected. This is the case for infinite executions. If a cycle is found, then a correctness violation has occurred. never { T0: if :: (true) -> goto T0 :: (q) -> goto accept fi; accept: if :: (true) -> goto T0 fi }

4 Translation of LTL formulae LTL formula Buchi automata Promela []<>p : always guaranteed that eventually p will become true at least once more. Written in Promela as: never { T0: if :: (true) -> goto T0 :: (p) -> goto accept fi; accept: if :: (true) -> goto T0 fi } 1 accepting state, 1 non-accepting state. The conditions are on the transitions of the automata, not on the states. true p

5 Translation of LTL formulae [](p U q) : always guaranteed that p remains true at least until q becomes true. Written in Promela as: never { T0: if :: (p) -> goto T0 :: (q) -> goto accept fi; accept: if :: (p || q) -> goto T0 fi } 1 accepting state, 1 non-accepting state. The conditions are on the transitions of the automata, not on the states. q p V q p

6 Translation of LTL formulae There is a translation algorithm (ltl manager). The translation first converts the formula to normal form, the translation recursively compiles the set of subformulae that must hold for each (reachable) state, and of its successor states. SPIN will convert LTL formulae into never claims automatically.

7 Satisfaction of LTL formulae LTL formula Buchi automata E.g. []<>p [](p U q) A B.a. accepts a word iff it forces execution through one or more accepting states infinitely often (acceptance cycle). LTL formula Buchi automata x global system f automata Sxf B. automata If language accepted by Sxf is empty, L(Sxf) = {}, then f is not satisfied. If there are no acceptance cycles in Sxf, then f is not satisfied. true p q p V q p

8 Satisfaction of LTL formulae Reasoning about product automata Formula []<>p system I product lang. includes system lang. f is true. an abstraction system II product lang. is empty. f is false. an abstraction ~p p true p

9 Satisfaction of LTL formulae Reasoning about product automata It is much easier to prove that the product language is empty, than it includes the system language. i.e. it is easier to prove that a formula does not hold. Therefore, we try to prove the negation of the formula of interest. This is the never claim. So: no execution sequence matches the never claim no acceptance cycles in product of system and never claim the formula holds If there is an acceptance cycle (the negated formula holds, the formula does not) there is a counter-example. Best-case: compute empty product, 0 states. If there is no acceptance cycle (the negated formula does not hold, the formula does hold) there is no counter-example. Worst-case: compute entire product, all states.

10 Satisfaction of LTL formulae Additional meta level operation In the LTL property manager, you can select all executions quantify over all paths. no executions quantify over no paths. Default is all executions.

11 Satisfaction of LTL formulae never claim a process expressing undesirable behaviour “matched” if it has an acceptance cycle, or negate LTL formula f never claim Buchi automata So we prove f with a never claim: formula []p []p <>p <>p quantifier all exec no exec all exec no exec matched <>~p []p []~p <>p some some some some branch branch branch branch not []p <>~p <>p []~p matched all all all all branches branches branches branches Summary

12 Behind the scenes checking is carried out on the fly - generate the graph as it is being searched must store states on a stack as they are visited how to cope with enormous state spaces? (e.g. >>10 8 ) memory M reachable states N state size S S <= M/N exhaustive search possible S > M/N ?? In general, we can remove states (safe) compress states (safe and unsafe)

13 Behind the scenes Partial Order Reduction Remove spurious interleavings of process behaviour static reduction method remove “extra” acceptance cycles exploit asynchronous communication overhead of time

14 Behind the scenes Storing visited states collision hash stack of hash table indices hash table of states “ordinary” hashing hash compact always hash to k bits (64) collapse reduce spurious “process” states every state: hash global variables processes channels

15 Behind the scenes Bistate Hashing (Supertrace) S is state size. M is memory size. N is no. of reachable states. What do you do when S> M/N and we don’t know N! There will be collisions, so let’s minimise them. The key is to choose m, the number of bits to represent a state. So we have: state hash value bitstate vector S bits m bits 2 m bits P = probability of collision N<M P <= 2 N-m-1 (n-m-1 should be small) N>=M P>= 1-2 m-n (so try to make n>>m) H f = M/N’ where N’= (1-P) * N H f >100 ==> 2 m is a good approximation of N

16 Behind the scenes S is state size. M=2 m is memory size (bits). N= 2 n is no. of reachable states. m is no. of hash bits. What is the probability of a collision? P = probability of collision N<M P <= 2 n-m-1 no states < memory N-M-1 is negative. P is small. N>=M P>= 1-2 m-n want |m-m| to be large. so make n >> m. Can we define a reliable indication of the coverage that has been achieved. (A true measure would involve exhaustive search!) Define: H f = M/N’ where N’= (1-P) * N Then, when H f >100 ==> 2 m is a good approximation of N.