Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

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.
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.
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
A Survey of Runtime Verification Jonathan Amir 2004.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
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:
UPPAAL Introduction Chien-Liang Chen.
Hybrid Systems Presented by: Arnab De Anand S. An Intuitive Introduction to Hybrid Systems Discrete program with an analog environment. What does it mean?
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.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
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.
Model Checking Büchi Pushdown Systems Presented by Rustan Leino Juncao Li and Fei Xie Dept. of Computer Science, Portland State University Thomas Ball.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
1 Translating from LTL to automata Book: Chapter 6.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
1 Completeness and Complexity of Bounded Model Checking.
November 18, 2004 Embedded System Design Flow Arkadeb Ghosal Alessandro Pinto Daniele Gasperini Alberto Sangiovanni-Vincentelli
Quantity  A generic mechanism to model performance In platform-based design, two pieces of information are required to capture the characteristics of.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Modeling continuous-time sub-systems in Metropolis Gabriel Eirea EE249 project 12/3/02 Mentors: Claudio Pinello Felice Balarin Yosinori Watanabe Howard.
System Design Research Laboratory Specification-based Testing with Linear Temporal Logic Li Tan Oleg Sokolsky Insup Lee University of Pennsylvania.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
1 Translating from LTL to automata. 2 Why translating? Want to write the specification in some logic. Want to check that an automaton (or a Kripke structure)
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
DAC June Automatic Trace Analysis for Logic of Constraints Xi Chen, Harry Hsieh University of California, Riverside Felice Balarin, Yosinori Watanabe.
Model Checking LTL over (discrete time) Controllable Linear System is Decidable P. Tabuada and G. J. Pappas Michael, Roozbeh Ph.D. Course November 2005.
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.
Maria-Cristina Marinescu Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology A Synthesis Algorithm for Modular Design of.
Verification technique on SA applications using Incremental 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.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
Model Checking Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
CS6133 Software Specification and Verification
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Formalizing Hardware/Software Interface Specifications
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Verification & Validation By: Amir Masoud Gharehbaghi
Concurrency Properties. Correctness In sequential programs, rerunning a program with the same input will always give the same result, so it makes sense.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
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.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
About Alternating Automata Daniel Choi Provable Software Laboratory KAIST.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Graphical editor for the Metropolis meta-model Jiagen Ding and Hongjing Zou Fall 2001.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
Automatic Verification
Program Synthesis is a Game
Propositional Calculus: Boolean Algebra and Simplification
Monitoring Programs using Rewriting
CSCI1600: Embedded and Real Time Software
Generating Optimal Linear Temporal Logic Monitors by Coinduction
CSCI1600: Embedded and Real Time Software
Translating Linear Temporal Logic into Büchi Automata
Presentation transcript:

Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation in Metropolis Framework. Guang Yang, Harry Hsieh, Xi Chen, Felice Balarin, Alberto Sangiovanni-Vincentelli. [2]Logic of Constraints: A Quantitative Performance and Functional Constraint Formalism. Xi Chen, Harry Hsieh, Felice Balarin, Yosinori Watanabe.

Design in Block Diagram Q-mgr real time Q-mgr power Q-mgr memory ProcessConnectionMediumQuantity Manager 2

Producer-Consumer Model process X name P 1 process X name P 2 process X name C medium S name M process X { port Read R; port Write W; void thread() { while (true) { x = R.read(); z = foo(x); W.write(z); } interface Read extends Port { update int read(); eval int nItems(); } interface Write extends Port { update int write(int data); eval int nSpace(); } medium S implements Read, Write { int n, space; int[] storage; int read() { … } int nItems() { … } int write(int data) () { … } int nSpace() { … } } 3 event stream

Mapping Function to Architecture System FunctionSystem Architecture BUS CPU 1 CPU 2 CPU 3 Mapping Implementation 4

Motivation System is nicely structured (opposed to arbitrary C++ code) – Single thread of control in a process – No sharing between processes – Model of computation determined by (passive) media Not only correct behavior is important, but also other aspects: – Virtual time – Real time – Power consumption (for embedded devices) – Memory consumption Quantity managers annotate events; properties can be formally checked and dynamically verified. Not only verify properties, but also enforce properties. 5

LTL (Linear Temporal Logic) L ::= a| ¬ L | L 1  L 2 | L 1  L 2 | X L | G L | F L | L 1 U L 2 | L 1 R L 2 a is a literal X – next G – global F – future U – until R – release L 1 U L 2 : L 1 R L 2 : Negated normal form: Contains only ¬   X U R, and ¬ only appears before literals. – F L ≡ true U LG L ≡ ¬ F ¬ L – ¬ X L ≡ X ¬ L – ¬ ( L 1 R L 2 ) ≡ ¬ L 1 U ¬ L 2 – ¬ ( L 1 U L 2 ) ≡ ¬ L 1 R ¬ L 2 L2L2 L2L2 L2L2 L2L2 L2L2 L2L2 L1  L2L1  L2 L1L1 L1L1 L1L1 L2L2 6 ¬L1¬L1 ¬L1¬L1 ¬L1¬L1 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L 1  ¬L 2

LTL in the Model constraint { ltl G( begin(P 1.write) → !begin(P 2.write) U end(P 1.write) && begin(P 2.write) → !begin(P 1.write) U end(P 2.write) ); } 7 process X name P 1 process X name P 2 process X name C medium S name M process X { port Read R; port Write W; void thread() { while (true) { x = R.read(); z = foo(x); W.write(z); } interface Read extends Port { update int read(); eval int nItems(); } interface Write extends Port { update int write(int data); eval int nSpace(); } medium S implements Read, Write { int n, space; int[] storage; int read() { … } int nItems() { … } int write(int data) () { … } int nSpace() { … } }

LOC (Logic of Constraints) Term ::= c | i | val(e[t]) | f (e[t]) | o(t 1, t 2, …, t n ) – c is a value. – i is the only index variable. – e is an event. – For t  Term, val(e[t]) represents the value of the t th occurance of e. – f (e[t]) is an annotation that returns the value of the t th occurance of e. – o is an n-ary operator that returns a value. LOC: a Boolean-valued term. Examples: – data (input [i]) = data (output [i]) – vt (display [i+100]) – vt (display [i]) 

LTL and LOC LTL and LOC are incomparable. LTL is good for liveness; LOC is good for safety. – It is easy to express “infinitely often” in LTL. G F p – To disprove a safety property in LOC, just find an i such that the constrain is violated. (i is unbounded but finite.) data (input [i]) = data (output [i]) vt (display [i+100]) – vt (display [i])  1000 Verifying simulation with LTL and LOC  Enforcing property with LTL (Büchi Automata)  Enforcing property with a subset of LOC 9

Büchi Automata A Büchi automaton is , S, S 0, , F  where  is a finite set of events. S is a finite set of states. S 0  S is a set of initial states.  : S    2 S is a transition function. F  2 S is a set of sets of final states. A run is s = [s 0, s 1, …] such that s i+1   (s i,  i ) where  i   is the i th input. A run s is accepting if  F k  F, s visits some states in F k infinitely often. 10

LTL (p U q)  Büchi Automata 11 p U q  q  (p  X (p U q))(  ) Init old: { } new: {p U q} next: { } old: {p U q} new: {q} next: { } old: {p U q} new: {p} next: {p U q} old: {p U q, q} new: { } next: { } q old: {p U q, p} new: { } next: {p U q} p old: { } new: { } next: { } true old: { } new: {p U q} next: { } true old: {p U q, q} new: { } next: { } old: { } new: { } next: { } Create an Init state. The old set contains sub- formulas that hold up to this point. The new set contains sub- formulas that need to hold in the future. The next set contains sub- formulas that need to hold at the next point. For p U q, split into two cases using (  ). Move atomic propositions (p and q in this case) from new to old. Take the conjunction of atomic propositions in old for the transition label. Create a new state whose new set equals the old state’s next set. The old set and the next set are empty. Since the new state’s old set contains no atomic proposition, the transition condition is simply true. States with the same sets can be merged. Finally, examine all states to find final states. Recall that F  2 S. For each sub-formula x U y, create F k such that:  f  F k. y  f.old  x U y  f.old F = {F k } now old new next

Enforcing Büchi Automata (1) Size: exponential Keep track of 2 sets of states: – The system states – The Büchi Automata’s states (one for each LTL constraint) 12 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA

Enforcing Büchi Automata (2) 13 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA !begin(P 1.write) U (end(P 1.read)  ready(M)) Do not make any transition if P 1 tries to write, but P 1.read has not ended, or M is not ready. end(P 1.read)  ready(M) !begin(P 1.write) true

Enforcing Büchi Automata (3) 14 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA Use heuristics when multiple transitions in BA are enabled. Maximize the number of events that can run – E.g., with events !begin(P 1.write), end(P 1.read), ready(M) and enabled transitions end(P 1.read)  ready(M), !begin(P 1.write) we choose the former transition. end(P 1.read)  ready(M) !begin(P 1.write) true s1s1 s2s2

Enforcing Büchi Automata (4) 15 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA Use heuristics when multiple transitions in BA are enabled. Try to lead the execution to a final state – E.g., with events !begin(P 1.write), end(P 1.read), ready(M) and enabled transitions going to s 1 (final), s 2 we choose the former transition. end(P 1.read)  ready(M) !begin(P 1.write) true s1s1 s2s2

Enforcing a Subset of LOC Hard to enforce LOC, but algorithms have been found to enforce a subset of LOC E.g., vt (display [i+100]) – vt (display [i])  1000 Generalize to var (event [i+n]) – var (event [i])  m Resolve to a constraint on an increasing variable Enforcing: – Easy for vt – simply refuse to increase if new update tends to violate a constraint – Hard for rt – static analysis necessary; may not be possible at all 16

Runtime Monitoring 17 LTL  BA Subset of LOC Checker Generation System FunctionSystem Architecture BUS CPU 1 CPU 2 CPU 3 Mapping Implementation

Case Study (1) The PIP (Picture-in-Picture) model has 22 concurrent processes, and 300+ media. 18 TS_DEMUXPES_PARSER MPEG USR_CONTROL JUNGGLERRESIZE

Case Study (2) Discovered a bug in the RESIZE module: Hard to manually fix it. Fix it with LTL enforcement: – G( end(P 1.write) → !begin(P 1.write) U end(C.read) ) G( end(P 2.write) → !begin(P 2.write) U end(C.read) ) G( end(C.read) → !begin(C.read) U (end(P 1.write)  end(P 2.write) ) ) Checking time linear in trace size. Memory consumption remains constant. – Time to generate the checker and to check 120,000 lines of trace: < 1m 19 P1P1 P2P2 C C may not read all of P 1 ’s output due to lack of handshaking; same for P 2.

Conclusion Use LTL to constrain behavioral property. Use LOC to constrain quantitative property (e.g., time, power consumption, etc). – [2] Logic of Constraints: A Quantitative Performance and Functional Constraint Formalism. Xi Chen, Harry Hsieh, Felice Balarin, Yosinori Watanabe. Not only verify constraints, but also enforce them, even if the implementation does not satisfy. Automatically generate verifier/enforcer from LTL and a subset of LOC. – Can be very effective in specifying coordination between threads. 20