1 / 25

CSE 522 UPPAAL – A Model Checking Tool

CSE 522 UPPAAL – A Model Checking Tool. Computer Science & Engineering Department Arizona State University Tempe, AZ 85287 Dr. Yann-Hang Lee yhlee@asu.edu (480) 727-7507. UPPAAL -- Introduction. A tool for modeling, simulation and verification of real-time systems.

osanna
Download Presentation

CSE 522 UPPAAL – A Model Checking Tool

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. CSE 522UPPAAL – A Model Checking Tool Computer Science & Engineering DepartmentArizona State University Tempe, AZ 85287 Dr. Yann-Hang Leeyhlee@asu.edu(480) 727-7507

  2. UPPAAL -- Introduction • A tool for modeling, simulation and verification of real-time systems. • Appropriate for systems that can be modeled as • a collection of non-deterministic processes with finite control structure and real-valued clocks (i.e. timed automata) • Networks of timed automata • communicate through channels and shared data structures. • Modeling language • channels, and locations • constants, data-variables (with bounded domains) and arrays • guards and assignments • templates with local clocks, data-variables, and constants • C subset

  3. Tool Overview System Editor • Draw Automata: locations, edges, etc. • Declare global and local constant, variables, and functions • Create instances of system and processes Simulator • Traces (state transitions): next, prev, replay, open, save, random • Message sequences Verifier • A<> p : p will inevitable become true, the automaton is guaranteed to eventually reach a state in which p is true.

  4. Example: Fischer’s Protocol (1) A well-known mutual exclusion protocol • a timed protocol where the concurrent processes check for both a delay and their turn to enter the critical section using a shared variable id. Protocol • Starting from the initial location • processes go to a request location, req, if id==0, which checks that it is the turn for no process to enter the critical section. • stay non-deterministically between 0 and k time units in req, • go to the wait location and set id to their pid • wait at least k time units, before entering the critical section CS if it is its turn, i.e. id==pid.

  5. Example: Fischer’s Protocol (2) id – shared variable, initialized 0 each process has it’s own timer (for delaying) Process i: while (true) { <noncritical section>; while id != -1 do {} id := i; delay K; if (id = i) { <critical section>; id := -1; } }

  6. Example: Fischer’s Protocol

  7. Locations Locations: to define the state of automaton. • System state is defined by the locations of all automata, the clock values, and the values of the discrete variables. Initial Locations • The beginning of the process. Each template must have exactly one initial location. Urgent Locations • Urgent locations freeze time. This forces the actual process to always make a transition without any delay. Committed Locations • A committed state cannot delay and the next transition must involve an outgoing edge of at least one of the committed locations.

  8. Locations and Edges n: int[0,5] a! Invariant, selection, guard, update, synchronization

  9. Channels in Uppaal • Used to synchronize two processes. • binary synchronization and blocking • an edge with synchronization label e! emits a signal on the channel e and that the enabled edge with synchronization label e? will synchronize with the emitting process. • Urgent Channels • synchronization via that channel has priority over normal channels and the transition must be taken without delay. • No clock guard allowed on edges using urgent channels. • Broadcast channel • allows 1-to-many synchronization. • sender is not blocked if there is no receiver.

  10. Declaration in Uppaal Integer • intnum1, num2; // integer variables with default domain. • inta[2][3]; // a multidimensional integer array. • int[0,5] b=0; // with the range 0 to 5 initialized to 0. Boolean • bool yes = true; //a boolean variable “yes initialize to true. • bool b[8], c[4]; // two boolean arrays b and c, with 8 and 4 elements Const • constint a = 1; // constant “a” with value 1 of type integer. • constbool No = false; //constant “No” with value false Clock • clock x, y; //two clocks x and y. Channel • chan d; // a channel. • urgent chan a, b ,c; //urgent channel.

  11. Verifying Properties (1) • E<> p: there exists a path where p eventually holds. • A[] p: for all paths p always holds. • E[] p: there exists a path where p always holds. • A<> p: for all paths p will eventually hold. • p --> q: whenever p holds q will eventually hold.

  12. Verifying Properties (2) E<>  A [ ]     A<>  E[ ] 

  13. Verifying Properties (3) Deadlock (state formula) • A state is a deadlock state if there are no outgoing action transitions neither from the state itself or any of its delay successors. Reachability • whether there exists a path starting at the initial state, such that a state formula is eventually satisfied (e.g. is it possible for a sender to send a message?) Safety • Something bad will never happen! (e.g. the temperature of the engine is always (invariantly) under a certain threshold) • (something good is invariantly true) Liveness • Something good will eventually happen! (e.g. when pressing the on button, then eventually the television should turn on)

  14. System Model in Uppaal System: • a list of processes to define a network of timed automata, i.e. concurrent processes. • global declaration Process: • instantiated from a parameterized template. Template: definition of a timed automaton • can be parameterized, e.g., automata for 4 tasks • have local declarations of variables, channels, and constants • templates without parameters are instantiated into exactly one process At a given time-point, transitions are enabled in the order of the process priorities.

  15. Additional Features in Uppaal Priority chan priority a < b, c; system P < Q, R; • At a given time-point, local and synchronization transitions are enabled in the order of process and channel priorities. User defined functions • C/C++/Java style • no recursive call, evaluated atomically and must be deterministic • compiled to byte-code, and executed at verification time on a small embedded stack machine.

  16. Example: Train Crossing (1) Stopable Area [3,5] [10,20] Crossing [7,15] Queue Gate River

  17. Example: Train Crossing (2) A railway control system which controls access to a bridge for several trains. The bridge is a critical shared resource that may be accessed only by one train at a time. A train can not be stopped instantly and restarting also takes time. • When approaching, a train sends an appr! signal. Thereafter, it has 10 time units to receive a stop signal. This allows it to stop safely before the bridge. • After these 10 time units, it takes further 10 time units to reach the bridge if the train is not stopped. • If a train is stopped, it resumes its course when the controller sends a go! signal to it after a previous train has left the bridge and sent a leave! signal.

  18. Example: Train Crossing (3) channels for “appr”, “stop”, “go”, and “leave” Queries • A[] forall (i : id_t) forall (j : id_t) trains(i).Cross && trains(j).Cross imply i == j • trains(1).Appr --> trains(1).Cross

  19. Example: Train Crossing (4) Train automata Gate automata

  20. Labels in Edges (1) (http://dmi.uib.es/~jproenza/SistEncTR/TheUppaalModelCheckerNEW.pdf) Edges are annotated with guards, updates, synchronizations and selections A guard is an expression which uses the variables and clocks of the model in order to indicate when the transition is enabled, i.e. may be fired. • Note that several edges may be enabled at an specific time but only one of them will be fired An update is an expression that is evaluated as soon as the corresponding edge is fired. Selections non-deterministically bind a given identifier to a value in a given range. • The other three labels of an edge are within the scope of this binding.

  21. Labels in Edges (2) Synchronization: the basic mechanism used to coordinate the action of two or more processes. • models for instance the effect of messages causes two (or more) processes to take a transition at the same time. Regular channel • fired between the processes paired with c! and c? for a channel c and when the guards of the edges are satisfied. • if there are several possible ways to have a pair c! and c?, one of them is non-deterministically chosen. • The update expression on an edge synchronizing on c! is executed first

  22. Committed Locations a! and b! are atomic Committed locations • useful for creating atomic sequences • a committed state cannot delay and the next transition must involve an outgoing edge of at least one of the committed locations • if any process is in a committed location, the next transition must involve an edge from one of the committed locations • if several processes are in a committed location at the same time, then they will interleave.

  23. Delay Transition and Invariants (1) When will the reset synchronization happen? Delay transitions model the passing of time without changing the current location. a delay transition (L, v) --(d)--> (L, v'), where d is a non-negative real, if and only if: • v' = v + d, where v+d is obtained by incrementing all clocks with d. • for all 0 <= d' <= d: v + d' satisfies Inv(L) • L contains neither committed nor urgent locations • no enabled edge with urgent synchronization

  24. Delay Transition and Invariants (2)

  25. Delay Transition and Invariants (3)

More Related