17.02.05Lecture51 Timed Automata II CS 5270 Lecture 5.

Slides:



Advertisements
Similar presentations
Model Checking for an Executable Subset of UML Fei Xie 1, Vladimir Levin 2, and James C. Browne 1 1 Dept. of Computer Sciences, UT at Austin 2 Bell Laboratories,
Advertisements

CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Simulation executable (simv)
Models of Concurrency Manna, Pnueli.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.
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?
Timed Automata.
UPPAAL Andreas Hadiyono Arrummaisha Adrifina Harya Iswara Aditya Wibowo Juwita Utami Putri.
ComS 512 Project John Altidor Michelle Ruse Jonathan Schroeder.
CSE 522 UPPAAL – A Model Checking Tool Computer Science & Engineering Department Arizona State University Tempe, AZ Dr. Yann-Hang Lee
Hybrid Approach to Model-Checking of Timed Automata DAT4 Project Proposal Supervisor: Alexandre David.
The Spin Model Checker Promela Introduction Nguyen Tuan Duc Shogo Sawai.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
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.
Formal Software Testing and Model Checking Generating Test Cases For a Timed I/O Automaton Model Leonid Mokrushin.
Ordering and Consistent Cuts Presented By Biswanath Panda.
CPSC 668Set 16: Distributed Shared Memory1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Petri Net Modeling for dynamic MM composite Object.
System-Level Types for Component-Based Design Paper by: Edward A. Lee and Yuhong Xiong Presentation by: Dan Patterson.
Real-Time System Requirements & Design Specs Shaw - Chapters 3 & 4 Homework #2: 3.3.1, 3.4.1, Add Error states to Fig 4.1 Lecture 4/17.
Timing analysis of an SDL subset in UPPAAL Anders Hessel Institution of Information Technology Department of Computer Systems Uppsala University M.Sc.
Abstract Verification is traditionally done by determining the truth of a temporal formula (the specification) with respect to a timed transition system.
CSC 8310 Programming Languages Meeting 2 September 2/3, 2014.
Lecture 6 Template Semantics CS6133 Fall 2011 Software Specification and Verification.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
1/20 Symbolic Execution and Program Testing Charngki PSWLAB Symbolic Execution and Program Testing James C.King IBM Thomas J.Watson Research Center.
UPPAAL Ghaith Haddad. Introduction UPPAAL is a tool for modeling, validation and verification of real-time systems. Appropriate for systems that can be.
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
1 VeriSoft A Tool for the Automatic Analysis of Concurrent Reactive Software Represents By Miller Ofer.
Transformation of Timed Automata into Mixed Integer Linear Programs Sebastian Panek.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
- 1 - Embedded Systems - SDL Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages.
CS 3850 Lecture 3 The Verilog Language. 3.1 Lexical Conventions The lexical conventions are close to the programming language C++. Comments are designated.
CS6133 Software Specification and Verification
Reactive systems – general
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
2/19/20031 Introduction to SMV. 2/19/20032 Useful Links CMU Model checking homepage SMV windows version
Lecture 81 Regional Automaton CS 5270 Lecture 8. Lecture 82 What We Need to Do Problem: –We need to analyze the timed behavior of a TTS. –The timed behavior.
Timed I/O Automata: A Mathematical Framework for Modeling and Analyzing Real-Time Systems Frits Vaandrager, University of Nijmegen joint work with Dilsun.
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
Communicating Real-Time State Machines (CRSM) State machines that communicate synchronously Unique unidirectional channels are used for the communication.
Petri Nets Lecturer: Roohollah Abdipour. Agenda Introduction Petri Net Modelling with Petri Net Analysis of Petri net 2.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Temporal Logic Model-checking with SPIN
Chapter 5 Introduction to VHDL. 2 Hardware Description Language A computer language used to design circuits with text-based descriptions of the circuits.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
Overview of Compilation Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 2.
1 An SDL Tutorial Two primary elements: –Structure –Identifies the various components of the system, and the communication paths among them. –Components:
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
UPPAAL Real-Time Systems Lab. Seolyoung, Jeong.
SS 2017 Software Verification Timed Automata
CPE555A: Real-Time Embedded Systems
Timed Automata II CS 5270 Lecture Lecture5.
CSEP590 – Model Checking and Automated Verification
Course: CS60030 FORMAL SYSTEMS
Presentation transcript:

Lecture51 Timed Automata II CS 5270 Lecture 5

Lecture52 Goals Timed Transition Systems: –Review –Definition –Timed behaviors. –Parallel composition –Reachability UPPAAL

Lecture53 Timed Transition Systems Timed Transition Systems = Transition Systems + Clock Variables. Clock variables. – Used to record the passage of (real) time. –Act like Timers. –Can be read. – Transitions constrained (guarded) by current values of clock variables. –Can be reset to 0 during a transition.  Continue to evolve (in real time) until reset.

Lecture54 Using Clock Variables Hot; y On-ac; xOK Off-ac x  5 Off-ac Spec. : Turn off ac if the temperature is OK or any time after 5 units of time has elapsed since turning it on. Turn on ac within 2 time units after receiving Hot signal. y ≤ 2

Using Clock Variables Hot; y On-ac; xOK Off-ac x ¸ 5 Off-ac y ≤ 2 Three components: Action on-ac Reset x In general, more than one clock can be reset. Guard y ≤ 2 In general, more than one constraint can be used.

Lecture56 State Invariants A clock constraint is associated with each state: state invariant –The system can stay in the state only as long as the state’s invariant is not violated. For time points which violate the invariant one expects an output transition to be enabled. –Otherwise a time deadlock.  The progress of time is blocked (in the model!).

Lecture57 Timed Transition Systems: Definition Clock Constraints: X, a finite set of clocks (clock variables). – x  X  (X), the set of clock constraints over X. –  (X) = x ≤ c | x ≥ c | x c |  1   2 | –c  Q  Q, the set of non-negative rational numbers. 2 X --- The set of subsets of X  X = {x, y} 2 X = { , {x}, {y}, {x, y} }

Lecture58 Timed Transition Systems TTS = (S, s in, Act, X, I,  ) –S is a finite set of states. – s in, initial state –Act, a finite set of actions –X, a finite set of clock variables. –I : S  (X), assigns a clock invariant to each state. –   S  Act  2 X   (X)  S, the transition relation.

9 Example s3 x > 2  y  3 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, add, {x}, True, s1) is a transition in TTS.

10 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, add, {x}, True, s1) is a transition in TTS. X = {x0, x1,..xn} True = x0 ≥ 0 X = {x, y} True = x  0

11 Example s3 x > 2  s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, data, {y}, True, s2) is a transition in TTS. (s2, ack.add, ;, x > 2, s3) is a transition in TTS. (s3, ack.data, ;, y ≤ 5, s0) is a transition in TTS

Lecture512 Behaviors s0s1s2 s3 s4 a b c d s0 a s1 b s2 c s3 s0 a s1 b s2 d s4 Are both paths (runs).

Lecture513 Behaviors s0s1s2 s3 s4 a ; x b c d s0 a s1 b s2 c s3 is NOT a run! s0 a s1 b s2 d s4 is a run. Computing behaviors is difficult. x = 1 x < 1 x ≥ 2

Lecture514 Behaviors TTS = (S, s in, Act, X, I,  ) We associate a “normal” transition system with TTS while taking time into account: – TS TTS = ( S, s in, Act  R,  ) –R, non-negative reals    S  Act  R  S TS TTS is, almost always, an infinite transition system!

Lecture515 Behaviors TTS = (S, s in, Act, X, I,  ) TS TTS = ( S, s in, Act  R,  ) S = S  V V --- Valuations –A valuation says what the current values of each clock variable is.  v : X R

Lecture516 Behaviors s0s1s2 s3 s4 a ; x b c d (s1, 0) (s2, 1.8) (s4,  ) are t-states. (s3, 5) is a t-state but not reachable. x = 1 x < 1 x ≥ 2

Lecture517 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, (2, 5) ) is a state; (s1, V) V(x) = 2 V(y) = 5 (s2, V’) is a state. V’(x) = 15 V’(y) = 0 (s2, (15, 0) )

Lecture518 Behaviors TTS = (S, s in, Act, X, I, !) TS TTS = ( S, s in, Act  R,  )  R, non-negative reals    S  Act  R  S S = S  V s in = (s in, V ZERO ) –V ZERO (x) = 0 for every x in X.

Lecture519 Behaviors There will be two types of transitions. Time pass move: –(s, v)  (s, v’)  t units of time pass starting from V.  V’ (x) = V(x) + t for every x. Instantaneous transition. –(s, v)  (s’, v’) –Some transition in the timed automaton is taken at v; the guard is satisfied; v’ is the same as v except for resets. t a

20 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, (0, 5))(s2, (1, 6) ) 1 Time- passing move?

21 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, (0, 5))(s1, (1, 7) ) 1 Time- passing move?

22 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, (0, 5)) 0 Time- passing move?

23 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s1, (0, 5))(s1, (2, 7.7) ) 2 Time- passing move?

24 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (3, 3) ) add (s1, (0, 3)) a transition in TS?

25 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (3, 3) ) add (s3, (0, 3)) a transition in TS?

26 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (3, 3) ) add (s1, (0, 4)) a transition in TS?

27 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (0, 0) ) add (s1, (0, 0)) a transition in TS?

28 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (0, 0) ) add (s1, (0, 0)) data (s2, (0, 0) ) Is this possible?

29 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s2, (3, 2))(s3, (3, 2)) ack.add (s3, (5, 5))(s0, (5, 5)) ack.data

30 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 TS TTS will have (uncountably) infinite number of states and transitions. (s0, (0, 0)) (s0, (.8,.8)).8 ………….. (s0, (1, 1)) 1

Lecture531 Timed Behaviors TTS = (S, S0, Act, X, I, !) TS TTS = ( S, s in, Act  R,  ) The timed behavior of TTS is defined as the behavior of TS TTS –Runs –computations

32 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (0, 0)) 1.6 (s0, (1.6, 1.6)) add (s1, (0, 1.6)) 2 (s1, (2, 3.6) data (s2, (2, 0))..…

Lecture533 Timed Behaviors Two consecutive time-passing moves can be amalgamated into one time passing move. (s1, (2,5)) 2 (s1, (4, 7)) 1.3 (s1, (5.3, 8.3)) can also be recorded as : –(s1, (2,5)) 3.3 (s1, (5.3, 8.3)) (s, V)  1 (s, V+  1 )  2 (s, (V+  1 )+  2 ) can also be recorded as: –(s, V)  1 +  2 (s, V+(  1 +  2 ))

Lecture534 Timed Computations TTS = (S, S0, Act, X, I, !) TS TTS = (S, S0, Act [ R, )) (s0, V0)  0 (s0, V0’) a 0 (s1, V1)  1 (s1, V1’) a 1 (s2, V2) …… induces the timed computation –(a 0,  0 ) (a 1,  0 +  1 ) …… (a n,  0 +   n ) Transition systems --- Computations Timed Transition Systems --- Timed Computations.

35 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (0, 0)) 1.6 (s0, (1.6, 1.6)) add (s1, (0, 1.6)) 2 (s1, (2, 3.6) data (s2, (2, 0)) (add, ? ) (data, ?) ….

36 Example s3 x > 2 s0s1 s2 add ; x data ; y ack.add ack.data y ≤ 5 (s0, (0, 0)) 1.6 (s0, (1.6, 1.6)) add (s1, (0, 1.6)) 2 (s1, (2, 3.6) data (s2, (2, 0)) (add, 1.6 ) (data, 3.6) ….

Lecture537 Example add ; x data ; y ack.add x > 2 ack.data y ≤ 5 (add, 1) (d, 10) (ack.a, 3) A timed computation?

Lecture538 Example add ; x data ; y ack.add x > 2 ack.data y ≤ 5 (add, 1) (d, 10) (ack.a, 3) A tmed computation? No! Time must increase monotonically.

Lecture539 Example add ; x data ; y ack.add x > 2 ack.data y ≤ 5 (a, 1) (ack.a, 3) (d, 10) A timed computation?

40 Example add ; x data ; y ack.add x > 2 ack.data y ≤ 5 (a, 1) (ack.a, 3) (d, 10) A timed computation? No! The order of execution must respect the specification!

Lecture541 Example add ; x data ; y ack.add x > 2 ack.data y ≤ 5 (a, 1) (d, 1) (ack.add, 10) A time computation?

Lecture542 Example x > 2 add ; x data ; y ack.add ack.data y ≤ 5 (a, 1) (d, 1) (ack.add, 10) A timed computation? Yes! Transitions are assumed to take zero time. Must rule out an infinite number of occurrences in finite time.

Lecture543 Zeno Computations x < 1 b a … (b, ½) ….(b, 3/4) ….(b, 15/16) …. (b, 31/32)…. We must define computations of timed transition systems carefully!

Lecture544 Parallel Composition TTS = TTS_1 || TTS_2 || …… || TTS_n Same principle as before: –Do common actions together –Take union of clock variables. –Take conjunction of the guards!

Lecture545 Reachability of Control States For a finite TS it is trivial to decide whether s is reachable in TS. For finite TTS, whether s is reachable in TTS is not easy to decide because TS TTS is an infinite object! But this can be done and this verification process can be automated. More involved (liveness) properties can also be verified effectively but not always efficiently.

CS Feb 2005Lecture546 An introduction to UPPAAL

Lecture547 What is UPPAAL? A toolbox for modeling, simulation and verification of real-time systems –Developed jointly by Uppsala University and Aalborg University –Often used for real-time controllers, communication protocols, etc. Consists of 3 main parts –a system description –a simulator –a verifier

Lecture548 System Description

Lecture549 System Description A system in UPPAAL: a set of concurrent processes A process: a timed-automaton with: –Clocks and data variables –data variables: int, bool, array of int/bool Scopes: global or local (to a process) –Both clocks and data variables! –Guards (on transitions) and invariants (on locations) are conditions on data variables and clocks

Lecture550 System Description Synchronization actions are described using communication channels Two processes communicate with each other via global data variables or synchronization on communication channels

Lecture551 System Description A system description in UPPAAL is composed of –Global declarations –Process templates –Process assignments –A system definition

Lecture552 System Description Overview of UPPAAL

Lecture553 Global declarations All the clocks, variables, constants and channels declared here are visible to all the processes in the system

Lecture554 Global declarations clock x, y; –two clocks x and y const a 1; –a constant a with value 1 int a; –an integer variable a in the default range from to int[1,10] b := 2; –an integer variable b in the range 1,…,10 that is initialized to 2 int a[2][3] := {{0,1,2},{3,4,5}}; –a two dimensional integer array a default range and its initialization bool a[3], b[5]; –two bit arrays a and b, with 3 and 5 elements respectively.

Lecture555 Global Declarations chan d; –A communication channel d –Actions performed by two processes when they synchronize with each other on channel d are denoted as d! (sending) and d? (receiving) urgent chan d; –When two processes are able to synchronize on channel d, they have to do it immediately. –No guard is allowed on transitions labeled with synchronization actions (eg. d!,d?) on urgent channels broadcast chan e; –Allows 1-to-many synchronization –A transition with label e! emits a broadcast on the channel e. –Any enabled transition with label e? will synchronise with the emitting process. No guard is allowed on these transitions

Lecture556 Process Templates Define a common control structures for the processes that are alike –Each process is an instantiation of a template Each template can have –symbolic variables and constants as parameters  Parameters are syntactically similar to declarations, but with no initializations  Eg. clock x, y; int i1, i2; chan a, b –local clocks and variables  Declared in the same way as global clocks and variables

Lecture557 Process Templates Draw the structure of the template here! Declare symbolic constants and variables here! Name of the template

Lecture558 Process Templates All clocks, variables, constants declared here are visible to process template P only

Lecture559 Process Templates An example of process template

Lecture560 Process Templates Locations –3 types: normal (with/without invariant), committed(C), urgent (U) –When the system enters a committed location, it must leave the location immediately:  Just a way of breaking up the effect of a transition into a sequence of steps. –urgent location: Only 0 units of time can be spent in this location.

Lecture561 Process Templates A guard –A conjunction of timing and data expressions –Written as a list of expressions, separated by commas  x < y, x <= 5, (a[0] + 1) != (a[1]*5) Timing expression: x ~ e or x – y ~ e –x, y : clocks; e: an integer expression –~  { =, ==, } Data expression: –involves constants and variables –same as in C/C++/Java

Lecture562 Process Templates Invariants –Same as guards, with no lower bounds on clocks Updates –A list of assignment expressions –Each assignment is of the form: x := e or a := e’  In x: = e, almost always e is 0.  x: a clock  a: a variable  e: an integer expression  e’: a data expression –Evaluated sequentially  a := 1, b := 2*a sets a to 1, b to 2.

Lecture563 Process Assignments Declare instances of process templates Each assignment has the form P := T(A); –P : a process name –T : a process template name –A : an argument list Examples: –P := Q();  Process P is an instance of template Q that has no parameter –S:=R(x,1);  Process S is an instance of template R that has two parameters - a clock and a constant

Lecture564 Process Assignments Instantiate your processes here!

Lecture565 System Definition Declare the set of processes in the system Eg. system P, Q; –A system consists of two processes P and Q Each process in the system must be either –a process that appears on the left-hand-side of a process assignment, or –a template with no parameter

Lecture566 Simulator

Lecture567 Simulator A validation tool that –allows users to interact and observe the behavior of the system during execution –visualise executions (i.e. symbolic traces) generated by the verifier Interface: divided into 4 sub-windows –Simulation control –Variable window –Process window –Message Sequence Chart

Lecture568 simulator control variable window process window Message sequence chart

Lecture569 Simulator Control Used to control the simulation and to select the (symbolic) state or transition to be visualized –Upper part: for step-by-step simulation  Displays all enabled transitions  Enables users to select an enabled transition to be fired –Lower part: displays the generated trace  A trace is an alternating sequence of location vectors and transitions.

Lecture570 Simulation Control use the mouse to select the transition to be fired press “Next” causes the system to fire the selected transition press “Reset” resets the simulated system to its initial state

Lecture571 Simulation Control the simulation always progresses from this highlighted element press “Replay” to replay the trace starting from the currently selected element. press “Prev” to highlight the element immediately preceding the current selection in the trace. press “Open” to open a file selector window for loading a trace from file. control the speed of simulation

Lecture572 Variable window Displays the values of data and clocks in the current state or transition selected in the trace

Lecture573 Process window Displays the process instances of the system –The current location of each automaton is marked with a red token –The transitions currently selected in the simulation control panel are highlighted

Lecture574 the selected transition

Lecture575 Message Sequence Chart Displays an MSC view of the generated trace –a vertical lines for each process –a horizontal line for each synchronisation point. synchronization point

Lecture576 Verifier

Lecture577 Verifier Used to check invariant and liveness properties of the system Requirement Specification Language A[ ] pFor all paths, p always holds E<> pThere exists a path where p will eventually hold E[ ] pThere exists a path where p always holds A<> pFor all paths, p will eventually hold p --> qWhenever p holds, q will eventually hold p : an expression that has no side-effect or state formula (conjunction of state locations)

Lecture578 Verifier Examples A[] not deadlock  true if the system is not deadlocked. –E<> p1.cs and p2.cs  true if the system can reach a state where both process p1 and p2 are in their locations cs. A[ ] p1.cs imply not p2.cs  true if whenever process p1 is in its location cs, the process is not in its location cs.

Lecture579 The selected property to be verified Press to verify the selected property Insert a new property Remove the selected property Show the comments in overview window the system is deadlock free verification results are shown here!