Automated Reasoning in Complex Theories and Applications to - - PowerPoint PPT Presentation

Automated Reasoning in Complex Theories and Applications to Verification

Viorica Sofronie-Stokkermans

University Koblenz-Landau (This presentation is based on joint work with

• W. Damm, J. Faber, M. Horbach, C. Ihlemann, S. Jacobs and D. Peuter)

Oldenburg, 2.07.2018

1

Motivation

Long-term goal of research in computer science

• use computers as ’intelligent assistants’ in

e.g. mathematics, engineering (and other fields) Main problem

• complex description of problems to be solved

→ complex systems, complex encoding

1

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs MATHEMATICS

• Theories from mathematical analysis

Functions over R

• monotone, bounded
• continuous, differentiable
• Algebraic structures

Monoids, groups, rings Lattices, Boolean algebras

• Logic

Classical logic Non-classical logics

• many-valued, fuzzy
• modal, dynamic, temporal
• ...

2

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs VERIFICATION MATHEMATICS Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Controllers Embedded software

3

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs VERIFICATION MATHEMATICS Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Controllers Embedded software

Program verification

int [] BubbleSort(int[] a) { int i, j, t; for (i :=| a | −1; i > 0; i := i − 1) { for (j := 0; j < i; j := j + 1) { if (a[j] > a[j + 1]){t := a[j]; a[j] := a[j + 1]; a[j + 1] := t}; }} return a}

• Does BubbleSort return a sorted array?
• Is a state with a certain property

reachable in ≤ k steps?

3

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs VERIFICATION MATHEMATICS Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Controllers

Inv flow Inv flow Inv flow Inv flow

3 1 1 2 2 3 4 4

Fill React Filter Dump

Check:

• No overflow
• Substances in the right proportion
• If substances in wrong proportion,

tank can be drained in ≤ 200s. Determine values for parameters such that this is the case 3

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs VERIFICATION MATHEMATICS Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Controllers

Train/Plane controllers

RBC braking + reaction distance

• Task: check collision freeness

3

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs VERIFICATION MATHEMATICS Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Controllers

Car controllers

Car platoon

• Task: check collision freeness

3

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras − test consistency Tasks − answer queries − limit search Tasks − construct proofs − check proofs VERIFICATION DATA BASES MATHEMATICS Tasks numeric domains − functions over − data types Theories − First−order logic − Datalog − ... Theories − numbers − programs − reactive/hybrid systems − cryptography − numbers − functions from/to numerical domains

safety/lifeness correctness crypt. prot. correctness/termination

4

Examples of application domains

Theories − numbers − polynomials − functions over numeric domains − algebras − test consistency Tasks − answer queries − limit search Tasks − construct proofs − check proofs VERIFICATION DATA BASES MATHEMATICS Tasks numeric domains − functions over − data types Theories − First−order logic − Datalog − ... Theories − numbers − programs − reactive/hybrid systems − cryptography − numbers − functions from/to numerical domains

safety/lifeness correctness crypt. prot. correctness/termination

Verification tasks can often be reduced to testing satisfiability/validity of logical formulae

4

Problems and goals

– 1st order logic is undecidable: cannot build an ’all-purpose’ program – theories do not occur alone: need to consider combinations of theories +

• ften fragments of theories occurring in applications are decidable

+

• ften provers for the component theories can be combined efficiently

Important: Identify theories (and extensions/combinations thereof) which are decidable (with low complexity) and relevant in applications

5

Efficient reasoning

• Possibility of limiting search
• Modular reasoning in complex theories

without loss of completeness

6

Example: A theory of doubly-linked lists

Reasoning about doubly-linked lists cf. also [Necula, McPeak 2005]

A p (p = null ∧ p.next = null → p.next.prev = p) A p (p = null ∧ p.prev = null → p.prev.next = p) ∧ c=null ∧ c.next=null ∧ d=null ∧ d.next=null ∧ c.next=d.next ∧ c = d | = ⊥

7

Example: A theory of doubly-linked lists

Reasoning about doubly-linked lists cf. also [Necula, McPeak 2005]

(c=null ∧ c.next=null →c.next.prev=c) (c.next=null ∧ c.next.next=null →c.next.next.prev=c.next (d=null ∧ d.next=null→d.next.prev=d) (d.next=null ∧ d.next.next=null→d.next.next.prev=d.next ∧ c=null ∧ c.next=null ∧ d=null ∧ d.next=null ∧ c.next=d.next ∧ c = d | = ⊥

7

Example: A theory of doubly-linked lists

Reasoning about doubly-linked lists cf. also [Necula, McPeak 2005]

(c=null ∧ c.next=null →c.next.prev=c) (c.next=null ∧ c.next.next=null →c.next.next.prev=c.next) (d=null ∧ d.next=null→d.next.prev=d) (d.next=null ∧ d.next.next=null→d.next.next.prev=d.next) ∧ c=null ∧ c.next=null ∧ d=null ∧ d.next=null ∧ c.next=d.next ∧ c = d | = ⊥

Extensions which also take the elements of the list: analogous? → Reasoning in complex theories

7

Complex Theories

Hierarchic Reasoning Example: T1 T1: Σ1-theory; T0 ⊆ T1 Σ0 ⊂ Σ1 f : R → R mon. T0 T0: Σ0-theory. R Can we use a prover for T0 as a blackbox to prove theorems in T1?

8

Complex Theories

Hierarchic Reasoning T1 T1: Σ1-theory; T0 ⊆ T1 Σ0 ⊂ Σ1 T0 T0: Σ0-theory. Can we use a prover for T0 as a blackbox to prove theorems in T1? Modular Reasoning Example: T1 T0 T2 T0: Σ0-theory. lists(R) ∪ arrays(R) Ti: Σi-theory; T0 ⊆ Ti Σ0 ⊆ Σi. Can we use provers for T1, T2 as blackboxes to prove theorems in T1 ∪ T2? Which information needs to be exchanged between the provers?

8

Overview

• Local theory extensions

Idea Definitions Hierarchical reasoning/Parametric complexity Recognizing local theory extensions

• Applications

Mathematics Verification

• Symbol Elimination/Synthesis

9

Example & Idea

R ∪ Mon(f ) ∪ (a ≤ b ∧ f (a) = f (b) + 1)

• G

| =⊥

Mon(f ) A x, y(x ≤ y → f (x) ≤ f (y))

10

Example & Idea

R ∪ Mon(f ) ∪ (a ≤ b ∧ f (a) = f (b) + 1)

• G

| =⊥

Mon(f ) A x, y(x ≤ y → f (x) ≤ f (y)) Problems:

• A prover for R does not know about f
• A prover for first-order logic may have problems with the reals and integers
• SMT provers may have problems with the universal quantifiers

→ Instantiation-based methods: incomplete or non-terminating

• ften answer “unknown” for satisfiable formulae

10

Example & Idea

R ∪ Mon(f ) ∪ (a ≤ b ∧ f (a) = f (b) + 1)

• G

| =⊥

Mon(f ) A x, y(x ≤ y → f (x) ≤ f (y)) Problems:

• A prover for R does not know about f
• A prover for first-order logic may have problems with the reals and integers
• SMT provers may have problems with the universal quantifiers

→ Instantiation-based methods: incomplete or non-terminating

• ften answer “unknown” for satisfiable formulae

Our goal: Identify situations in which we can restrict to certain instances without loss of completeness

10

Idea

R∪Monf ∧ (a < b ∧ f (a) = f (b) + 1)

• G

| = ⊥ Limit search space R ∪ Monf [G] ∪ G | = ⊥ → sound and complete

G ∪ Mon(f ) a < b f (a) = f (b) + 1 A x, y(x ≤ y → f (x) ≤ f (y))

11

Idea

R∪Monf ∧ (a < b ∧ f (a) = f (b) + 1)

• G

| = ⊥ Limit search space R ∪ Monf [G] ∪ G | = ⊥ → sound and complete Hierarchical reasoning

G ∪ Mon(f )[G] a1 = f (a) a < b b1 = f (b) f (a) = f (b) + 1 a ≤ b → f (a) ≤ f (b) b ≤ a → f (b) ≤ f (a)

The following are equivalent: (1) R ∪ Monf [G] ∪ G | = ⊥ (2) R ∪ Monf [G]0 ∪ G0 ∪ Def | = ⊥ (Purification)

11

Idea

R∪Monf ∧ (a < b ∧ f (a) = f (b) + 1)

• G

| = ⊥ Limit search space R ∪ Monf [G] ∪ G | = ⊥ → sound and complete Hierarchical reasoning

Definitions G0 ∪ Mon(f )[G]0 ∪ Con[G]0 a1 = f (a) a < b b1 = f (b) a1 = b1 + 1 a ≤ b → a1 ≤ b1 b ≤ a → b1 ≤ a1 a = b → a1 = b1

The following are equivalent: (1) R ∪ Monf [G] ∪ G | = ⊥ (2) R ∪ Monf [G]0 ∪ G0 ∪ Def | = ⊥ (Purification) (3) R ∪ Monf [G]0 ∪ G0 ∪ Con(Def) | = ⊥ (Hierarchical reduction)

11

Idea

R∪Monf ∧ (a < b ∧ f (a) = f (b) + 1)

• G

| = ⊥ Limit search space R ∪ Monf [G] ∪ G | = ⊥ → sound and complete Hierarchical reasoning

Definitions G0 ∪ Mon(f )[G]0 ∪ Con[G]0 a1 = f (a) a < b b1 = f (b) a1 = b1 + 1 a ≤ b → a1 ≤ b1 b ≤ a → b1 ≤ a1 a = b → a1 = b1

The following are equivalent: (1) R ∪ Monf [G] ∪ G | = ⊥ (2) R ∪ Monf [G]0 ∪ G0 ∪ Def | = ⊥ (Purification) (3) R ∪ Monf [G]0 ∪ G0 ∪ Con(Def) | = ⊥ (Hierarchical reduction)

11

Idea

R∪Monf ∧ (a < b ∧ f (a) = f (b) + 1)

• G

| = ⊥ Limit search space R ∪ Monf [G] ∪ G | = ⊥ → sound and complete Hierarchical reasoning

Definitions G0 ∪ Mon(f )[G]0 ∪ Con[G]0 a1 = f (a) a < b −−− − b1 = f (b) a1 = b1 + 1 a ≤ b → a1 ≤ b1 b ≤ a → b1 ≤ a1 a = b → a1 = b1

The following are equivalent: (1) R ∪ Monf [G] ∪ G | = ⊥ (2) R ∪ Monf [G]0 ∪ G0 ∪ Def | = ⊥ (Purification) (3) R ∪ Monf [G]0 ∪ G0 ∪ Con(Def) | = ⊥ (Hierarchical reduction) SAT iff a > b!

11

Idea

Σ1 extension of Σ0 with function symbols K set of Σ1-clauses; Task: Check whether T0 ∪ K ∪ G | =⊥ Abstraction: Consider only certain instances Approximate extension functions with “partial” functions T0 ∪ K ∪ G | = ⊥ → T0 ∪ K[G] ∪ Con[G] ∪ G | = ⊥ Soundness: T0 ∪ K[G] ∪ Con[G] ∪ G | =⊥ ⇒ T0 ∪ K ∪ G | =⊥ Completeness: T0 ∪ K[G] ∪ Con[G] ∪ G | =⊥⇒ E “partial” model If every “partial” model can be embedded into a total model of T0 ∪ K ∪ G then T0 ∪ K ∪ G | =⊥

12

Local theory extensions

Local theory extensions [Ganzinger,VS,Waldmann’04, VS’05] T0 theory; Σ0 ⊆ Σ0 ∪ Σ1, K equational clauses f ∈ Σ1; T1 = T0 ∪ K T0 ⊆ T0 ∪ K is local, if for all sets of ground clauses G, T0 ∪ K ∪ G | =⊥ iff T0 ∪ K[G] ∪ G | =⊥ K[G] = {Cσ | C ∈ K and for every term f (t) in Cσ, where f ∈ Σ1, f (t) is a ground term in G}

13

Reasoning in local theory extensions

Locality: T0 ∪ K ∪ G | =⊥ iff T0 ∪ K[G] ∪ G | =⊥ Problem: Decide whether T0 ∪ K[G] ∪ G | =⊥ Solutions: 1: Use SMT(T0+UIF): completeness guaranteed only if K[G] ground 2: Hierarchical reasoning [VS’05] reduce to satisfiability in T0: applicable in general; sound and complete → parameterized complexity

14

Local theory extensions

[GSW’04, VS’05] K set of equational clauses; T0 theory; T1 = T0 ∪ K

• Definition. T0 ⊆ T1 is local iff for all sets of ground clauses G,

T0 ∪ K ∪ G | =⊥ iff T0 ∪ K[G] ∪ G | =⊥

Hierarchical reasoning

• 1. Locality:

T0∪K[G]∪G | = ⊥ → O(nk) clauses

• 2. Purification:

T0∪K[G]0∪G0∪Def | = ⊥ → linear

• 3. Hierarchical reduction: T0∪K[G]0∪G0∪Con(Def) |

= ⊥ → +O(n2) clauses

• 4. Satisfiability test in T0 (prover for T0 – blackbox)

→ g(nk) Parametric complexity for T1

15

Local theory extensions

Various notions of locality, depending of the instances to be considered (closure operators [Ihlemann,Jacobs,VS’08, Ihlemann,VS’10]) Implementation: H-PILoT [Ihlemann,VS’09] How to recognize local theory extensions?

• Embeddability of partial into total models [Ganzinger,VS,Waldmann’04,VS’05]
• Transfer of locality [VS’07, Ihlemann,VS’10]

Combinations of local extensions are often local → modularity

• Saturation (under resolution) [Basin,Ganzinger’96’01, VS’07, Horbach,VS’13,’14]

Saturation ⇒ (order) locality

16

Examples of local theory extensions

Theories − numbers − polynomials − functions over numeric domains − algebras Tasks − construct proofs − check proofs MATHEMATICS

Extensions of a theory T0 with:

• free functions [VS’05]
• monotone functions [VS’05,’08], [Ihlemann,VS’07,’10]

Theories from mathematical analysis [VS’08,Damm,Ihlemann,VS’11]

• boundedness conditions (linear combinations)
• monotone functions + bounds (linear combinations)
• bounds on slopes

(linear combinations)

• convexity/concavity

+ continuity/differentiability Theories from algebra

• semilattices and lattices
• MV-algebras; G¨
• del algebras [VS,Ihlemann’07];
• Description logics [VS’08]
• Sets + measures → probabilities, durations [Bender,VS’2017]

17

Examples of local theory extensions

VERIFICATION Tasks numeric domains − functions over − data types Theories − numbers − programs − reactive/hybrid systems − cryptography

safety/lifeness correctness crypt. prot. correctness/termination

Theories of data structures [VS’07,’08c,Ihlemann,Jacobs,VS’08]

• fragments of the theory of “Arrays” und “Pointers”
• theories of recursive data structures + recursive functions
• “Update” axioms
• Verification:

Programs (data structures) [VS’06,’07] [Ihlemann,Jacobs,VS’08] Train systems [Faber,Jacobs,VS’06,07], [Faber,Ihlemann,Jacobs,VS’10] Hybrid systems (chemical plant controllers) [Damm,Ihlemann,VS’11], [VS’13] Systems of cars [Damm,Horbach,VS’16]

• Security

[VS’06,’09] Cryptography → encode(decode(x)) = x decode(encode(x)) = x

18

Verification

S specification → ΣS signature of S; TS theory of S → TS transition constraint system (TCS) defined by S

• Init(x):

formula describing the initial state

• Tr(x, x′): changes of variable values during transitions

Given: Ψ formula (e.g. safety property)

• Invariant checking

(1) | =TS Init(x) → Ψ(x) (Ψ holds in the initial state) (2) | =TS Ψ(x) ∧ Tr(x, x′)→Ψ(x′) (If Ψ holds before it also holds after update)

• Bounded model checking:

Check whether, for a fixed k, states violating Ψ are reachable by runs of TS of length at most k, i.e. for all 0 ≤ j ≤ k: Init(x0) ∧ Tr1(x0, x1) ∧ · · · ∧ Trn(xj−1, xj) ∧ ¬Ψ(xj) | =TS ⊥

19

Parametric verification

Given: Safety property (formula Φ)

• 1. Verification: Check if constraints on parameters guarantee safety

If not, construct model which does not satisfy Φ.

• 2. Synthesis:

Infer relationships between parameters,

• resp. properties of the functions modeling the changes

which ensure that the safety property Φ holds Here: Invariance of safety property Note: We used similar ideas for bounded reachability

20

General method

[VS’10, VS’13, VS’16] Verification → hierarchical reasoning in local theory extensions Synthesis → hierarchical QE in local theory extensions Examples:

• Verification of controllers:

− Train systems [Jacobs,VS’06],

[Faber,Jacobs,VS’07],[Faber,Ihlemann,Jacobs,VS’10]

− Chemical plants [VS’10, Damm,Ihlemann,VS’11] − Hybrid systems (possibly interconnected) [VS’13,Damm,Horbach,VS’15]

21

Example: ETCS Case Study (AVACS project)

Simplified version of ETCS Case Study [Jacobs,VS’06, Faber,Jacobs,VS’07] Number of trains: n ≥ 0 Z Minimum and maximum speed of trains: 0 ≤ min < max R Minimum secure distance: lalarm > 0 R Time between updates: ∆t > 0 R Train positions before and after update: pos(i), pos′(i) : Z → R

22

Example: ETCS Case Study (AVACS project)

Simplified version of ETCS Case Study [Jacobs,VS’06, Faber,Jacobs,VS’07]

Update(pos, pos′) :

• A

i (i = 0 → pos(i) + ∆t∗min ≤ pos′(i) ≤ pos(i) + ∆t∗max)

• A

i (0 < i < n ∧ pos(i − 1) > 0 ∧ pos(i − 1) − pos(i) ≥ lalarm → pos(i) + ∆t ∗ min ≤ pos′(i) ≤ pos(i) + ∆t∗max) ...

23

Example: ETCS Case Study (AVACS project)

Safety property: No collisions Safe(pos) : A i, j(i<j→pos(i)>pos(j)) Inductive invariant: Safe(pos)∧Update(pos, pos′)∧¬Safe(pos′) | =TS ⊥ where TS is the extension of the (disjoint) combination R ∪ Z with two functions, pos, pos′ : Z → R Idea: Axioms define chains of local theory extensions: Z ∪ R ⊆ Z ∪ R ∪ Safe(pos) ⊆ Z ∪ R ∪ Safe(pos) ∪ Update(pos, pos′) Hierarchical reduction to reasoning in R ∪ Z

24

Example: ETCS Case Study (AVACS project)

To check: T2 T2 = T1 ∪ Update(pos, pos′) T2 ∪ ¬Safe(pos′)

• G

| =⊥ T1 T1 = T0 ∪ Safe(pos) T0 T0 = R ∪ Z

25

Example: ETCS Case Study (AVACS project)

To check: T2 T2 = T1 ∪ Update(pos, pos′) T2 ∪ ¬Safe(pos′)

• G

| =⊥ ⇓ T1 T1 = T0 ∪ Safe(pos) T1 ∪ G ′(pos) | =⊥ ⇓ T0 T0 = R ∪ Z T0 ∪ G ′′ | =⊥ Φ(c, cpos′, dpos, n, lalarm, min, max, ∆t) | =⊥ Method 1: SAT checking/ Counterexample generation Method 2: Quantifier elimination relationships between parameters which guarantee safety

25

Example: ETCS Case Study (AVACS project)

[Faber,Ihlemann,Jacobs,VS’10] Verification of train systems with complex track topology Idea: Reduce complexity by exploiting modularity at various levels specification / verification / structurally

26

Main goal: exploit modularity at various levels

[Faber,Ihlemann,Jacobs,VS’10] Verification of train systems with complex track topology

• 1. Specification
• Use the modular language COD [Hoenicke,Olderog’02], which allows

us to separately specify – processes (as Communicating Sequential Processes, CSP), – data (using Object-Z, OZ), and – time, durations (using the Duration Calculus, DC).

27

Main goal: exploit modularity at various levels

[Faber,Ihlemann,Jacobs,VS’10] Verification of train systems with complex track topology

• 2. Verification
• Verification tasks: linear track; incoming, outgoing trains

Data structures Pointers; 2 Sorts: Trains Segments → Safety checking: reasoning in complex data structures → Solution: hierarchical and modular reasoning

27

Main goal: exploit modularity at various levels

[Faber,Ihlemann,Jacobs,VS’10] Verification of train systems with complex track topology

• 3. Structurally

→ Complex track topology (Assumption: No cycles; degree at most 2)

• decomposition into family of linear tracks (may overlap)
• prove that safety of whole system follows from

(1) safety for the controller of a linear track and (2) compatibility of controllers on jointly controlled trains.

• Synthesis: - Constraints on parameters which guarantee safety

27

Further extensions (Systems of LHA)

[Damm, Horbach, VS: FroCoS’15] Modularity results and small model property results for (decoupled) families of linear hybrid automata Sensors + Communication Channels Examples:

sideback back sidefront

7 1 10 5 3

Car platoon

Safety properties: A i1, . . . , ik φsafe(i1, . . . , il)

Collision free: A i, j(lane(i)=lane(j) ∧ pos(i)≥pos(j) ∧ i=j → pos(i)−pos(j)>d)

28

Model: Families of similar interacting system

Model families {S(i) | i ∈ I} consisting of an unbounded number

• f similar interacting systems.
• Model the interaction
• Model the systems S(i)
• Model the topology updates

29

Model: Families of similar interacting systems

Model families {S(i) | i ∈ I} consisting of an unbounded number

• f similar interacting systems.
• Model the interaction

→ structures (I, {p : I → I}p∈P) P = PS ∪ PN

The functions in P model the way the systems perceive their neighbors PS sensors: PN: neighborhood links

sideback back sidefront

7 1 10 5 3

Car platoon

next next next next f1 f2 f3 f4

sideback(7) = 3 back(7) = 3 front(7) = nil sidefront(7) = 10

29

Model: Families of similar interacting systems

Model families {S(i) | i ∈ I} consisting of an unbounded number

• f similar interacting systems.
• Model the interaction

→ structures (I, {p : I → I}p∈P)

• Model the systems S(i)

→ hybrid automata

29

Model: Spatial families of LHA

Model families {S(i) | i ∈ I} consisting of an unbounded number

• f similar interacting systems.
• Model the interaction

→ structures (I, {p : I → I}p∈P)

• Model the systems S(i)

→ hybrid automata

• Model the topology updates

→ Topology automaton

Example: Update(front, front′) A i

• i=nil ∧ Prop(i) ∧ ¬

E j(ASL(j, i)) → front′(i)=nil

• A

i

• i=nil ∧ Prop(i) ∧

E j(ASL(j, i)) → Closestf(front′(i), i)

• A

i

• i=nil ∧ ¬Prop(i) → front′(i)=front(i)
• ASL(j, i):

j = nil ∧ lane(j) = lane(i) ∧ pos(j) > pos(i) j is ahead of i on the same lane Closestf (j, i): ASL(j, i) ∧ A k(ASL(k, i)→pos(k) ≥ pos(j)) j is ahead of i; no car between them. 29

Verification

Is safety property an inductive invariant?

30

Verification

Is safety property an inductive invariant? Local extensions: use H-PILoT

• Unsatisfiable

→ Safety invariant

• Satisfiable

→ Model

30

Verification

Is safety property an inductive invariant? Local extensions: use H-PILoT

• Unsatisfiable

→ Safety invariant

• Satisfiable

→ Model → Simulation [J. Wild, BSc Thesis 2018]

30

Overview

• Local theory extensions

Idea Definitions Hierarchical reasoning/Parametric complexity Recognizing local theory extensions

• Applications

Mathematics Verification

• Symbol elimination/Synthesis

31

Parametric Systems

[VSS, CADE’2011] [VSS, CADE’2013]

parameters

ub lb i Sorting algorithm

a a’

Under which conditions is a′ sorted?

h f

• Cond. f s.t. T(t)∈[Tm, TM]?

RBC braking + reaction distance

Under which conditions no collision?

Car platoon

Under which conditions no collision? [Jacobs, VSS: ENTCS’2006] [Horbach, VSS: FroCoS’2015]

32

Synthesis: Parametric instructions

d1 = 3; d2 = a[4] while (nondet()) { d1 = a[d1+1]; d2 = h(d2) } Task: Determine conditions on h under which Ψ := d2 ≈ a[d1 + 1] is an inductive invariant.

33

Synthesis: Parametric Instructions

d1 = 3; d2 = a[4] while (nondet()) { d1 = a[d1+1]; d2 = h(d2) } Task: Determine conditions on h under which Ψ := d2 ≈ a[d1 + 1] is an inductive invariant. Solution:

• Ψ holds in the initial state: d2 = a[4] = a[3 + 1] = a[d1 + 1].
• Ψ invariant under updates iff

d2 ≈ a(d1 + 1) ∧ d′

1 ≈ a(d1 + 1) ∧ d′ 2 ≈ h(d2) ∧ d′ 2 ≈ a(d′ 1 + 1) |

=⊥

33

Synthesis: Parametric Instructions

d1 = 3; d2 = a[4] while (nondet()) { d1 = a[d1+1]; d2 = h(d2) } Task: Determine conditions on h under which Ψ := d2 ≈ a[d1 + 1] is an inductive invariant. Solution:

• Ψ holds in the initial state: d2 = a[4] = a[3 + 1] = a[d1 + 1].
• Ψ inductive invariant iff

d2 ≈ a(d1 + 1) ∧ d′

1 ≈ a(d1 + 1) ∧ d′ 2 ≈ h(d2) ∧ d′ 2 ≈ a(d′ 1 + 1) |

=⊥ Use symbol elimination in theory extensions to find Γ which guarantees unsatisfiability [VS, IJCAR 2016]

• Elim. d1, d′

1, d′ 2

→ Γ = A d2(h(d2) ≈ a(d2 + 1))

33

Synthesis: Example 2

d1 = 3; d2 = a[4]; d3 = 1; while (undet()) { d1 = a[d1+1]; d2 = a[d2+1] + (1-d3); d3 = d3/2 } Task: Prove If a array with increasingly sorted elements, then always d2 ≥ a[d1 + 1]

34

Synthesis: Example 2

d1 = 3; d2 = a[4]; d3 = 1; while (undet()) { d1 = a[d1+1]; d2 = a[d2+1] + (1-d3); d3 = d3/2 } Task: Prove If a array with increasingly sorted elements, then always d2 ≥ a[d1 + 1] Solution: Check whether Ψ = d2 ≥ a[d1 + 1] inductive invariant

34

Synthesis: Example 2

d1 = 3; d2 = a[4]; d3 = 1; while (undet()) { d1 = a[d1+1]; d2 = a[d2+1] + (1-d3); d3 = d3/2 } Task: Prove If a array with increasingly sorted elements, then always d2 ≥ a[d1 + 1] Solution: Check whether Ψ = d2 ≥ a[d1 + 1] inductive invariant

• Ψ holds in the initial state: d2 = a[4] = a[3 + 1] = a[d1 + 1].
• Ψ invariant under updates iff

d2 ≥ a[d1 + 1] ∧ Sorted(a) ∧ Update(d, d

′) ∧ d′ 2 < a[d′ 1 + 1] |

=⊥

Update(d, d

′) := d′ 1 = a[d1+1] ∧ d′ 2 = a[d2+1]+(1−d3) ∧ d′ 3 = d3/2

Sorted(a) := A i, j(i ≤ j → a[i] ≤ a[j]).

24

Synthesis: Example 2

d1 = 3; d2 = a[4]; d3 = 1; while (undet()) { d1 = a[d1+1]; d2 = a[d2+1] + (1-d3); d3 = d3/2 } Task: Prove If a array with increasingly sorted elements, then always d2 ≥ a[d1 + 1] Solution: Check whether Ψ = d2 ≥ a[d1 + 1] inductive invariant

• Ψ holds in the initial state: d2 = a[4] = a[3 + 1] = a[d1 + 1].
• Ψ invariant under updates iff

d2 ≥ a[d1 + 1] ∧ Sorted(a) ∧ Update(d, d

′) ∧ d′ 2 < a[d′ 1 + 1] |

=⊥

Update(d, d

′) := d′ 1 = a[d1+1] ∧ d′ 2 = a[d2+1]+(1−d3) ∧ d′ 3 = d3/2

Sorted(a) := A i, j(i ≤ j → a[i] ≤ a[j]). Formula satisfiable ⇒ Ψ not inductive invariant

34

Synthesis: Example 2

d1 = 3; d2 = a[4]; d3 = 1; while (undet()) { d1 = a[d1+1]; d2 = a[d2+1] + (1-d3); d3 = d3/2 } Task: Prove If a array with increasingly sorted elements, then always Ψ := d2 ≥ a[d1 + 1] Solution: Check whether Ψ = d2 ≥ a[d1 + 1] inductive invariant

• Ψ holds in the initial state: d2 = a[4] = a[3 + 1] = a[d1 + 1].
• Ψ invariant under updates iff

d2 ≥ a[d1 + 1] ∧ Sorted(a) ∧ Update(d, d

′) ∧ d′ 2 < a[d′ 1 + 1] |

=⊥

Update(d, d

′) := d′ 1 = a[d1+1] ∧ d′ 2 = a[d2+1]+(1−d3) ∧ d′ 3 = d3/2

Sorted(a) := A i, j(i ≤ j → a[i] ≤ a[j]). sorted.

Use symbol elimination in theory extensions to find Γ which guarantees unsatisfiability Γ = d3 ≤ 1 → Invariant: d2 ≥ a[d1 + 1] ∧ d3 ≤ 1

34

Invariant Synthesis

Method for invariant synthesis [Peuter, VSS, SYNT’2018] Input: T = (Init, Update, Σ) transition system; ΣP; Ψ univ. Output: Inductive Invariant I over ΣP s.t. I | = Ψ 1: I := Ψ 2: while I is not an inductive invariant for T do: if Init | = I then return “no univ. inductive invariant entails Ψ” if I is not preserved under updates then Γ: elim. primed symb. & symb. not in ΣP from I ∧ Update(Σ, Σ′) ∧ ¬I ′; I := I ∧ Γ 3: return I is an inductive invariant

35

Invariant Synthesis

Method for invariant synthesis [Peuter, VSS, SYNT’2018] Input: T = (Init, Update, Σ) transition system; ΣP; Ψ univ. Output: Inductive Invariant I over ΣP s.t. I | = Ψ 1: I := Ψ 2: while I is not an inductive invariant for T do: if Init | = I then return “no univ. inductive invariant entails Ψ” if I is not preserved under updates then Γ: elim. primed symb. & symb. not in ΣP from I ∧ Update(Σ, Σ′) ∧ ¬I ′; I := I ∧ Γ 3: return I is an inductive invariant [Peuter, VSS, SYNT 2018] Conditions under which algorithm correct and complete Situations in which it terminates

35

Conclusions

Theory Applications Efficient reasoning Verification

• Theories
• Deductive verification case studies
• Theory extensions

with Damm, Faber, Ihlemann, Jacobs, Horbach

• Chains of theory extensions
• Model generation → Simulation
• Theory combinations
• Synthesis ongoing work with D. Peuter

Hierarchic, modular reasoning Parameterized complexity

• Abstraction refinement

Interpolation Model generation Implementation H-PILoT Cryptography first steps Symbol Elimination, Interpolation Knowledge representation

36