Behavior models and verification

http://d3s.mff.cuni.cz

Behavior models and verificationLecture 1

Jan Kofroň, František Plášil

2Jan Kofroň, František Plášil, Lecture 1

Sylabus I.

Mathematical structures for behavior modeling:labeled transition systems, Kripke structures, Timed automata, Markov chains

Specification of system properties temporal logics: LTL, CTL, TCTL, PCTL,

Basic verification tasksequivalence checking and model checking


Sylabus II.

Decidability and complexity of equivalence checking and model checking in dependence of the type of the model

Software tools for model checking

Hard issues in formal verification infinite-state systemsstate explosion problem

Strategies to fight it


Grading

Final grades will be determined by the quality of homework and the result of the final exam in the following ratio:

55% Assignments (two homeworks)45% Final exam

>= 80 of 100 ~ 1

>= 71 ~ 2

>= 62 ~ 3

Final exam Written test


Information

Available at the course web page:

http://d3s.mff.cuni.cz/teaching/nswi101/


Teaching@D3S

http://d3s.mff.cuni.cz/teaching/nswi101/


Need: Striking stories

Ariane 5, 1996False angle of attackcaused by incorrect altitude data following a software exception and the rocket self-destructed in 37 seconds after launch

The software exceptionan overflow in the conversion of a 64-bit floating-point number to a 16-bit signed integer value

=> an operand error.

Direct cost 500.000.000 EUR, indirect cost 2.000.000.000 EUR



The operand error occurred because of an unexpected high value of the horizontal velocity sensed by the platform.

The value was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in higher horizontal velocity values.



Intel: Pentium FDIV bug, 1994

Cost $500 000 000



Mars Climate OrbiterNASA: SEPTEMBER 30, 1999The peer review preliminary findings indicate that one team used English unitswhile the other used metric units for a key spacecraft operation

Mars Polar Lander Dec. 1999The leading theory is that a surface contact detector located on the landing struts mistakenly interpreted the force of the landing strut's deployment as contact with the surface, causing the landing rockets to shut down prematurely and the probe to impact at too high a velocity.



Shutdown of USS Yorktown (CG-48), 1997

A sailor mistakenly typed 0 in a field of the kitchen inventory application

Subsequent division by this field caused an arithmetic exception, which propagated through the system, led to power shutdown for about 3 hours



Sensor failure caused not detecting a human in the seat. In turn, the airbag malfunction (failing in a car crash) appeared.

In 2015, Nissan recalled 3.5 millions of cars to fix this

Airbag problems reported by other car manufacturers in 2016

General Motors – GMC, Chevrolet, Buick, Cadillac



New device introduced into Boeing 737 MAX (MCAS)

To compensate too steep take-off



MCAS relies on single sensor

MCAS can reset itself after a pilot intervention

Info on MCAS was not put into manuals!

Two aircrafts crashed (2018 and 2019)

All passengers died

The aircrafts were grounded



A nice collection available at

http://www5.in.tum.de/persons/huckle/bugse.html


Context: HW and SW reliability

Complex (mostly reactive) systemsHW circuits (processors, …)

Communication protocols

Traffic control (traffic lights on intersections)

Air-traffic control

Mission-critical

Cyber Physical Systems (IoT,…)

SW code in generalDrivers, OS parts…


Achieving system reliability

Experimental methodsTesting

(applied to the system itself)

Simulation (experimenting with a model of a system)

Formal methodsDeductive verification

Theorem proving

Equivalence checkingComparing two specifications (models)

Model checking Checking a particular property of a model (even code)

Kripke structure


Model Checking

open

start

empty

close

empty

close

start

close

heat

start

heat

CTL

𝑨𝑮(𝐬𝐭𝐚𝐫𝐭 → 𝑨𝑭 𝐡𝐞𝐚𝐭)

Model

Property specification

Model checker

Property satisfied

Property violated

Errorreport


What makes model-checking software difficult?

Kripke structureopen

start

empty

close

empty

close

start

close

heat

start

heat

CTL

Model


Model checker

Property satisfied

Property violated

Errorreport




start

empty

close

empty

close

start

close

heat

start

heat

CTL

Model


Model checker

Property satisfied

Property violated

Errorreport

▪ State explosion Problems using existing checkers:

▪ Property specification ▪ Output interpretation

▪Model Construction


Model Construction Problem

ModelProgram

void add(Object o) {buffer[head] = o;head = (head+1)%size;}

Object take() {…tail=(tail+1)%size;return buffer[tail];}

Gap

methods, inheritance, dynamic creation, exceptions, etc.

States and transitions

Programming Languages

Model Description Languages

Semantic gap:

open

start

empty

close

empty

close

start

close

heat

start

heat Model checker




start

empty

close

empty

close

start

close

heat

start

heat

CTL

Model


Model checker

Property satisfied

Property violated

Errorreport




“Between the window open and the window close, button X can be pushed at most twice.”

[]((open /\ <>close) ->((!pushX /\ !close) U

(close \/ ((pushX /\ !close) U(close \/ ((!pushX /\ !close) U

(close \/ ((pushX /\ !close) U(close \/ (!pushX U close))))))))))

…is rendered in LTL as...

Difficult to formalize a requirement in temporal logic


Property Specification Problem

(((_collect(heap_b) == 1)\

&& (BoundedBuffer_col.instance[_index(heap _b)].head ==BoundedBuffer_col.instance[_index(heap _b)].tail) )\

|| ((_collect(heap _b) == 3)\&& (BoundedBuffer_col_0.instance[_index(heap _b)].head ==

BoundedBuffer_col_0.instance[_index(heap _b)].tail) )\|| ((_collect(heap _b) == 0) && TRAP))

Heap.b.head == Heap.b.tail

Forced to state property in terms of model rather than source

We want to write source level specifications...

We are forced to write model level specifications...


Property Specification Problem




start

empty

close

empty

close

start

close

heat

start

heat

CTL

Model


Model checker

Property satisfied

Property violated

Errorreport





State space

Model induces state space

combination of states of particular parts (behavior of involved processes)

potentially exponential in size of model

State space explosion = Problem of too many states induced by the model

Moore’s law and algorithm advances can help

Holzmann (author of Spin): 7 days (1980) ==> 7 seconds (2000) ==> 0.x seconds (2011)

BUT: Explosive state growth in software inherently limits scalability




start

empty

close

empty

close

start

close

heat

start

heat

CTL

Model


Model checker

Property satisfied

Property violated

Errorreport





Output Interpretation Problem

ModelProgram

void add(Object o) {buffer[head] = o;head = (head+1)%size;}

Object take() {…tail=(tail+1)%size;return buffer[tail];}

Gap

Error trace

Must map lines of source program onto model description

Mapping to source is made difficult by

Semantic gap & clever encodings of complex features multiple optimizations and transformations

Raw error trace may be 1000’s of steps long

Over-approximations in abstractions may yield infeasible error traces (how to decide if feasible or not?)

open

start

empty

close

empty

close

start

close

heat

start

heat

Errorreport


Labeled Transition System (LTS)

x:=0; y:=0;

for i:=1 to 3 do

(x:=x+1; y:=y+1)

x:=x+1y:=0x:=0 y:=y+1

x:=x+1

y:=y+1x:=x+1y:=y+1


Labeled Transition System (LTS)

Labeled Transition System

Is a triple 𝑆, 𝐴𝑐𝑡,→

𝑆 set of states (domain)

𝐴𝑐𝑡 set of labels (actions)

→ transition relation: →⊆ 𝑆 × 𝐴𝑐𝑡 × 𝑆


LTS Reminds Finite Automaton

LTSIs a triple 𝑆, 𝐴𝑐𝑡,→

Tracestring(sequence) of labels following a path in an LTS

𝐴𝑐𝑡 = 𝐿, typically enhanced by (internal action)

Finite Automaton𝑆, 𝐴𝑐𝑡,→, 𝐼𝑛𝑖𝑡𝑆𝑡𝑎𝑡𝑒𝑠, 𝐴𝑐𝑐𝑒𝑝𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑒𝑠

word


LTS notation


LTS illustrating the concepts

Trace preorder

Preorder: a relation

reflexive

transitive

antisymetric, i.e., 𝑎 ≤ 𝑏 ∧ ¬ 𝑎 = 𝑏 → ¬ 𝑏 ≤ 𝑎

Not required!


Trace preorder


LTS semantics

Semantics ~ equivalence

Many ways to define equivalence

How alternatives (branches) in LTS are handled

Branching spectrum

Trace

Failures

. . .

Simulation

Strong bisimilarity


LTS: Linear time/Branching time equivalence spectrum

strong bisimilarity

2-nested simulation equivalence

ready simulation equivalence

possible-futures equivalenceready trace equivalence

readiness equivalence failure trace equivalence

failure equivalence

completed trace equivalence

trace equivalence

simulation equivalence


LTS: Behavior equivalence – trace equivalence

Trace based (behavior) equivalence

trace preorder determines trace equivalence

𝑡𝑟𝑎𝑐𝑒𝑠 𝑠 = 𝑤 ∈ 𝐴𝑐𝑡∗ 𝑠→𝑤

𝑠′ 𝑓𝑜𝑟 𝑠′ ∈ 𝑆}

𝑠 ≤𝑡 𝑡 ↔ 𝑡𝑟𝑎𝑐𝑒𝑠(𝑠) 𝑡𝑟𝑎𝑐𝑒𝑠(𝑡)

Trace equivalence =𝑡

𝑠 =𝑡 𝑡 ↔ 𝑠 ≤𝑡 𝑡 ∧ 𝑡 ≤𝑡 𝑠


LTS: Behavior equivalence – trace eq.

Trace equivalence =𝑡

𝑠 =𝑡 𝑡 ↔ 𝑠 ≤𝑡 𝑡 ∧ 𝑡 ≤𝑡 𝑠

Notice nondeterminism

𝑠, 𝑡, 𝑢 ∈ 𝑆 of an 𝑆, 𝐴𝑐𝑡,→

Informally: =𝒕 does not reflect the structural differences in the LTS graphs

s

a

cb

t

b c

aa

u

a

cbb c

aa

=t =t


LTS: Behavior equivalence – trace eq.

Trace equivalence ver. Language equivalenceFinite Automaton 𝑆, 𝐴𝑐𝑡,→, 𝐼𝑛𝑖𝑡𝑆𝑡𝑎𝑡𝑒𝑠, 𝐴𝑐𝑐𝑒𝑝𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑒𝑠 , it accepts words

LTS 𝑆, 𝐴𝑐𝑡,→ , accepts traces

What makes a differenceA prefix of a trace w is also a valid trace

w can be infinite!

LTS → Automaton(i) Make all the states accepting, choose an 𝐼𝑛𝑖𝑡𝑆𝑡𝑎𝑡𝑒

(ii) Büchi automaton (𝜔 regular language)Coping with infinite traces

Automaton → LTSIntroduce a sentinel (“end of trace” label)

Consider only the traces ending with sentinel


Comments on LTS traces and languages

LTS with finite # of states

plus init state and final states → finite automaton,

depending upon the semantics of accepting a trace: regular language

finite traces

omega regular language

infinite traces

LTS with infinite # of states

type 0 language in general Turing machine acceptance


LTS: Behavior equivalence – simulation eq.

Simulation preorder and equivalencesimulation determines simulation equivalence

A relation 𝑅 ⊆ 𝑆 × 𝑆 is a simulation iff

whenever 𝑠, 𝑡 ∈ 𝑅, then for each 𝑠→𝑎𝑠′ there is 𝑡 →

𝑎𝑡′ such that 𝑠′, 𝑡′ ∈ 𝑅

Simulation preorder 𝑠 ≤𝑠 𝑡 iff

there is (exists) a simulation 𝑅 such that 𝑠, 𝑡 ∈ 𝑅

Simulation equivalence 𝑠 =𝑠 𝑡 iff 𝑠 ≤𝑠 𝑡 ∧ 𝑡 ≤𝑠 𝑠

s

a

cb

t

b c

aa

u

a

cbb c

aa

≤ss

s

R2

R1


LTS: Behavior equivalence – bisimilarity

Strong BisimilarityA relation 𝑅 ⊆ 𝑆 × 𝑆 is a bisimulation iff whenever 𝑠, 𝑡 ∈ 𝑅, then

for each 𝑠→𝑎𝑠′ there is 𝑡 →

𝑎𝑡′ such that 𝑠′, 𝑡′ ∈ 𝑅

for each 𝑡 →𝑎𝑡′ there is 𝑠→

𝑎𝑠′ such that 𝑠′, 𝑡′ ∈ 𝑅

(Strong) bisimilarity equivalence

𝑠 ~ 𝑡 iff there is (exists) a bisimulation 𝑅 such that 𝑠, 𝑡 ∈ 𝑅



Strong Bisimilarity

¬ 𝑠 𝑢

¬ 𝑢 𝑡

¬ 𝑡 𝑠

s

a

cb

t

b c

aa

u

a

cbb c

aa



Strong Bisimilarity

x y

c

𝑥 𝑦

c

c

c

c


LTS: Behavior equivalence – determinism

Influence of determinism

If an 𝑇 = 𝑆, 𝐴𝑐𝑡 ,→ is deterministic, then ~,= 𝑠, = 𝑡 are equal

u

a

cb

s

a

cb

t

a

cb


LTS specification – Process Algebras

(A) theory of concurrency

Way to capture LTS

Equational reasoning

Most knownCSP (Hoare), CCS (Milner), ACP (Bergstra, Klop),

-Calculus (Milner, Parrow, Walker)

Application areas – LTS modeling:concurrent systems

communication protocols

electronic circuits, production systems, biochemical processes


Process Algebras

ACP style Process Algebra

Focus on algebraic approachOrganized in different equational theories

Process theoryMinimal

with sequential processes

with recursive processes

with parallel processes

with abstraction

with probability

Different semantical models (there is a standard one: ~ i.e. bisimilarity)


Example

𝐴 = 𝑎. 𝑏. and 𝐵 = 𝑏. 𝑐.

• - sucessfull termination

• - deadlock – null process

• 𝑎, 𝑏, 𝑐 – primitive actions (processes)

• . concatenation ~ sequence of processes

𝐴 || 𝐵 ~ parallel execution


State space of A || B


Algebra of Communicating Processes

Features:Parallelism𝑀 || 𝑎. 𝑏. + 𝑏. 𝑐.

Actions are atomic (interleaving … )!

Communication (synchronization)(𝑏, 𝑐) = 𝑑

particular pair of actions becomes another action

Abstraction 𝑖1,𝑖2 𝑎. 𝑖1. 𝑖2. 𝑏. = 𝑎. . 𝑏.

listed actions become internal

The resulting theory Algebra of Communicating Processes (ACP)


ACP axioms

Let x, y be variablesx + y = y + x A1 commut. +(x + y) + z = x + (y + z) A2 assoc. +x + x = x A3 idempot. +(x + y). z = x.z + y.z A4 right distr. + and .(x .y) . z = x .(y . z) A5 assoc. .x + = x A6 neutral element. x = A7 null process

Note z. (x + y) = z.x + z.y is not included (nondeterministic choice)!


Parallelism: Interleaving Concurrency

If 𝐴 and 𝐵 are processes which cannot communicate, then

the parallel composition 𝐴 || 𝐵 executes 𝐴 and 𝐵 arbitrarily interleaved For example:

𝐴 = 𝑎. 𝑏. and 𝐵 = 𝑏. 𝑐. ,

then 𝐴 || 𝐵 can execute

𝑎, 𝑏, 𝑏, 𝑐 or 𝑏, 𝑎, 𝑐, 𝑏 or 𝑎, 𝑏, 𝑐, 𝑏, etc.

The || operator can be eliminated:

𝐴 || 𝐵 = 𝑎. (𝑏. 𝑏. 𝑐. + 𝑏. (𝑏. 𝑐. + 𝑐. 𝑏. )) + 𝑏. (𝑎. (𝑏. 𝑐. + 𝑐. 𝑏. ) + 𝑐. 𝑎. 𝑏. )


State space of A || B


Parallelism: Interleaving Concurrency and Communication

𝐴 and 𝐵 as before, but now they communicate on action 𝑏

The result of a communication is action 𝑑: 𝑏, 𝑏 = 𝑑

formally 𝐴 and 𝐵 together execute action 𝑑

Again, the || operator can be eliminated:

𝐴 || 𝐵 = 𝑎. 𝑏. 𝑏. 𝑐. ε + 𝑏. 𝑏. 𝑐. ε + 𝑐. 𝑏. ε + 𝑑. 𝑐. ε + 𝑏. 𝑎. 𝑏. 𝑐. ε + 𝑐. 𝑏. ε + 𝑐. 𝑎. 𝑏. ε


State space of A || B with communication

Assuming 𝑏, 𝑏 = 𝑑


Enforcing communication

By encapsulating (disabling) certain actions, communication can be enforced.

New process operator: 𝐻(_), with 𝐻 ⊆ 𝐴.

Process 𝐻(𝑥) is like 𝑥, but cannot execute actions 𝑎 ∈ 𝐻

For example,

𝑏 (𝐴| 𝐵 = 𝑎. 𝑑. 𝑐.

The b actions of 𝐴||𝐵 are encapsulated/disabled


Building concurrent systems

Specify separate components

Specify the communication actions between these components

Construct parallel compositions of components

Encapsulate certain actions to enforce communication


References

Process Algebra, J.C.M. Baeten and W.P. Weijland. Nr 18 in Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, 1990. (2nd edition to appear this year)

Algebraic specification of communication protocols, S. Mauw and G.J. Veltink. Nr 36 in Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, 1993.

*Introduction to Process Algebra, W.J. Fokkink. Texts in Theoretical Computer Science. Springer-Verlag, Berlin, 2000.

Handbook of Process Algebra, J.A. Bergstra and A. Ponse and S.A. Smolka (Eds). Elsevier Science B.V. 2001.

A gentle introduction to Process Algebras, Rocco De Nicola. Available at http://www.pst.ifi.lmu.de/Lehre/sose-2013/formale-spezifikation-und-verifikation/intro-to-pa.pdf

Documents

Behavior models and verification