SS 2018 Software Verification Strategic Reasoning

Slides:



Advertisements
Similar presentations
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
Advertisements

Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
Model Checking I What are LTL and CTL?. and or dreq q0 dack q0bar.
CS6133 Software Specification and Verification
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.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
Review of the automata-theoretic approach to model-checking.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Abstract Verification is traditionally done by determining the truth of a temporal formula (the specification) with respect to a timed transition system.
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 Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications 1.
Epistemic Strategies and Games on Concurrent Processes Prakash Panangaden: Oxford University (on leave from McGill University). Joint work with Sophia.
Lecture 81 Optimizing CTL Model checking + Model checking TCTL CS 5270 Lecture 9.
CS 395T Game-Based Verification of Contract Signing Protocols.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation - Formal verification -
Symbolic Algorithms for Infinite-state Systems Rupak Majumdar (UC Berkeley) Joint work with Luca de Alfaro (UC Santa Cruz) Thomas A. Henzinger (UC Berkeley)
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Strategic Reasoning with Game Description Language Ji Ruan, Prof. W. van der Hoek, Prof. M. Wooldridge Department of Computer Science From Specific Game.
Software Synthesis Participants: Omri Ajchenbaum and Daniel Hasson Supervised by Dr. Hillel Kugler Mid-Project presentations: February 2016.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Model Checking Lecture 1: Specification Tom Henzinger.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
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.
Krishnendu ChatterjeeFormal Methods Class1 MARKOV CHAINS.
SS 2017 Software Verification Timed Automata
SS 2017 Software Verification Automated Verification
SS 2017 Software Verification Bounded Model Checking, Outlook
SS 2017 Software Verification SMT Solving, Partial Order Methods
SS 2017 Software Verification Probabilistic modelling – DTMC / MDP
Prof. Dr. Holger Schlingloff 1,2 Dr. Esteban Pavese 1
Prof. Dr. Holger Schlingloff 1,2 Dr. Esteban Pavese 1
CSPs: Search and Arc Consistency Computer Science cpsc322, Lecture 12
SS 2017 Software Verification LTL monitoring
SS 2017 Software Verification Software Model Checking 2 - Parallelism
CSPs: Search and Arc Consistency Computer Science cpsc322, Lecture 12
SS 2018 Software Verification LTL Satisfiability applied
SS 2018 Software Verification ML, state machines
SS 2017 Software Verification CTL model checking, BDDs
VINO ‘11 My speech at Holger Schlingloff.
SS 2017 Software Verification Tableaus, CTL model checking
Software Verification 2 Automated Verification
Alternating tree Automata and Parity games
Software Verification 2 Automated Verification
SS 2017 Software Verification Modal Logics
CSEP590 – Model Checking and Automated Verification
Software Verification 2 Automated Verification
Formal Methods in software development
CSCI1600: Embedded and Real Time Software
Producing short counterexamples using “crucial events”
Instructor: Aaron Roth
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Formal Methods in software development
Presentation transcript:

SS 2018 Software Verification Strategic Reasoning Prof. Dr. Holger Schlingloff 1,2 Dr. Esteban Pavese 1 (1) Institut für Informatik der Humboldt Universität (2) Fraunhofer Institut für offene Kommunikationssysteme FOKUS

Recap Syntax of TCTL? Semantics? Model checking? What is a region? What is a DBM?

Multi-Agent Systems Example: Robots and Carriage circular track, one carriage, two robots which can push if one robot pushes, the carriage moves in the corresponding direction if both robots push or no robot pushes, the carriage does not move

Models transition system for carriage M ⊨ EG+ pos1 M ⊨ EG+pos1 wait s0  on wait push s1 push on transition system for carriage M ⊨ EG+ pos1 M ⊨ EG+pos1 M ⊨ AG+EF+pos1 and for robots wait, push s0

Is CTL expressive enough? A: No matter which (enabled) transitions are taken,  holds in the system E: There is a way to control the system such that  holds EG+ pos1: There is a strategy to stay in pos1 EG+pos1: There is a strategy to avoid in pos1 Who is deciding what to do? What if robot 1 and robot 2 are independent agents (actors, players, …)? Robot 1 „wants“ to keep the cart in pos1 Robot 2 „wants“ to avoid that the cart is in pos1

New Modalities  i  : There is a strategy for robot i to enforce that  holds, no matter what the other robot does M ⊭  1  G+ pos1: There is no strategy for robot 1 to enforce that the cart stays in pos1 (robot 2 may always push it away) M ⊨  2  G+pos1: There is a strategy for robot 2 to enforce that the cart avoids pos1, no matter what robot 1 does (in pos0 – push; in pos2 – wait) Valid or not? M ⊨  1  F+ pos1 M ⊨  1  G+pos1 M ⊨  2  F+pos1 M ⊨  2  ( pos0 U+ pos1) M ⊨  1  G+( pos0  Xpos2)

Strategies What is a strategy, then? Need to extend the notion of a transition system A concurrent game structure is a tuple CGS = (Agt, St, Act, δ, s0) which consists of a finite set of agents or players Agt = {a1,…, an}, a non-empty set of states St, a set of individual actions Act, a transition relation δ  St x 2(Agt x Act) x St that determines whether the successor state s’ is reachable from state s by a combined action α = {(a1, αa1), …, (an, αan)}, and an initial state s0  St. Example: Agt = {1,2}, St={q0, q1, q2}, Act={wait, push}, s0=q0, δ={(q0,(push, wait), q1), (q0,(push, push), q0), …}

Strategies Given a CGS, a (memoryless) strategy si for agent ai in a concurrent game structure is a function si: St  Act. That is, a strategy tells an agent which action to choose in a particular state. A combined action α is consistent with the strategies {s1 … sk} for agents {a1 … ak} in state s if (ai, si(s))  α for all i. An execution following strategies {s1, …, sk} for agents {a1, …, ak} is an execution (s0, α0, s1, α1, …), where every αi is consistent with the strategies in si. Remark 1: Determinism, final states, acceptance, … Remark 2: Given strategies for all agents in a deterministic game structure, there is only one possible execution following these strategies.

Turn-based deterministic two-player games TDCGS = (Agt, St, Act, δ, s0, avail, turn), where (Agt, St, Act, δ, s0)  CGS, i.e. has agents Agt = {a1, a2}, states St = Sta1 x Sta2, Act = Acta1  Acta2, s0St, transition relation δ: St x Act  St; avail  Agt x St x Act is an availability relation that defines whether an individual action is available to an agent at a state, turn: St  Agt is a turn-function indication which players may act, and avail (aj, s)   iff turn(s) = ai, for i{1,2}. Clearly, for each TDCGS there is an equivalent CGS (i.e., TDCGS are special CGS)

Example Train-Gate-problem: If out of gate, the train can issue a request The gate can grant or deny the request If granted, the train my move into the gate The gate can reopen after the train left

Properties Whenever the train is out of the gate and does not have a grant to enter the gate, the controller can prevent it from entering the gate: AG* ((out_of_gate ∧ ¬grant) →  ctr G* out_of_gate) Whenever the train is out of the gate, the controller cannot force it to enter the gate: AG* (out_of_gate → ¬  ctr F* in_gate) AG* (out_of_gate → [[ ctr]] G* out_of_gate) Whenever the train is out of the gate, the train and the controller can cooperate so that the train will enter the gate: AG* (out_of_gate →  ctr  train F* in_gate) Whenever the train is out of the gate, it can eventually request a grant for entering the gate, in which case the controller decides whether the grant is given or not: AG* (out_of_gate →  train F*(request ∧  ctr F* grant ∧  ctr G* ¬grant)) Whenever the train is in the gate, the controller can force it out in the next step: AG* (in_gate →  ctr X out_of_gate).

Coalitions and ATL If there are more than two agents / players, some of them may want to build coalitions. Let Agt = {a1,…, an}, then  ai, aj, ak  means „agents ai, aj, and ak can collaborate to bring about “ (or something which is wirkungsgleich) Semantics: There is a common strategy for {ai, aj, ak} such that  holds if this strategy is followed ATL::= p |  | (ATL  ATL) |  A X ATL |  A G * ATL |  A (ATL U* ATL) where A  Agt is a subset of all agents. CTL is a subset of ATL, where E =  Agt and A =   i.e., EF*  =  Agt  F*, AG* =   G* , etc.

ATL vs. CTL Consider the ATL formulas   G* ((out_of_gate ∧ ¬grant) →  ctr G* out_of_gate)   G* (out_of_gate → [[ ctr]] G* out_of_gate) They provide more information than the CTL formula AG*(out_of_gate → EG* out_of_gate) While the CTL formula only requires the existence of a computation in which the train is always out of the gate, the two ATL formulas guarantee that no matter how the train behaves, the controller can prevent it from entering the gate, and no matter how the controller behaves, the train can decide to stay out of the gate. ATL: R. Alur, T. A. Henzinger, and O. Kupferman. Alternating-time Temporal Logic. Journal of the ACM, 49:672–713, 2002. Slides: https://pdfs.semanticscholar.org/presentation/75e1/bfb9cfd964f2723f76a609124d2ff467c3a6.pdf

Example Two robots {r1, r2} working in a factory with three machines {m1, m2, m3} Machines can be busy, or idle and waiting to be serviced by a robot Robots can be idle, or servicing a particular machine There can be at most one robot servicing a machine at any particular moment in time Model: Agt = {m1, m2, m3, r1, r2} St = {busy, idle}3 x {idle, serv1, serv2, serv3}2 Actions for the machines: {go_idle, go_busy} Actions for the robots: {go_idle, go_servi} Properties: There exists a strategy for the robots such that every machine is eventually served There exists a strategy for the machines such that always a machine is idle …

ATL model checking In principle, ATL MC is no harder than CTL MC The MC algorithms of ATL and CTL are very similar The function Pre, when given a set A of players and a set  of states, returns the set of states q such that from q, the players in A can cooperate and enforce the next state to lie in .

Complexity of ATL MC Complexity is O(|M| * ||) This does not hold for ATL* (doubly exponential) Also other extensions (ATL with fairness, ATL with memory, ATL with real time, ATL with knowledge and belief, etc.) are all highly complex

Implementation: MCMAS MCMAS is an OBDD-based MC for MAS supports ATL with additional epistemic operators runs currently only on Linux-based systems (or VMs) Structure of an MCMAS agent: local states actions availability relations („protocol“) transition relation („evolution“) Structure of an ISPL program agents evaluation (for abbreviations in formulas) initial states groups (for abbreviations in formulas) fairness constraints ATL formulas to be checked