FATAL ERROR: Evento Imprevedibile … o no

FATAL ERROR: Evento Imprevedibile … o no

Enrico TronciDipartimento di Informatica, Università di Roma “La Sapienza”, Via Salaraia 113,

00198 Roma, Italy, [email protected], http://www.dsi.uniroma1.it/~tronci

Incontri 2003-2004 con la Facoltà di Scienze Matematiche Fisiche e Naturali 3 Dicembre 2003

mailto:[email protected]




http://www.dsi.uniroma1.it/~tronci




2

This program has executed an illegal operation and will be terminated

Error code: 56

Press any key to restart your system

3

Verification Game

Given:a system Sys (e.g. hardware, software, hybrid, etc) and an specifications Spec for Sys (e.g. what Sys should or should not do)

We want to know:If system Sys satisfies the given specifications Spec.

4

Examples

… is an undesired state for Windows XX

This program has executed an illegal operation and will be terminated

Error code: 56

Press any key to restart your system

1.1

1.1= 3.7

… is an undesired state for ANY Microprocessor FPU (… Pentium 2 included … )

A CRASH is an undesired state for rockets (e.g. Arianne V), airplanes, trains, cars, …

5

An approximate answerBUG HUNTING: Testing + Simulation

System (Model)

Compute output by Simulation or by running the actual

system when possible

… u(3) u(2) u(1) u(0)

Input sequence (stimulus)

Output sequence

y(0) y(1) y(2) y(3) …

Define initial state + parameters

Observerchecks that output sequence ok

6

Example (Testing 1) x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

0

1 3

4

1 1

2

Spec: x(t) < 5.I.e. no state with x(t) >= 5 is reachable.

Sim length: 101, 2, 1, 2, 1, 1, 2, 2, 2, 1

Spec does not fail on this run

2

1

2

2

2

21 1

7

Example (Testing 2) x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

2

0

1 3

4

5

2

1 11

2 2


Sim length: 61, 2, 1, 2, 1, 2

Spec FAIL

8

Testing: Obstructions (1)Generation of targeted testing sequences can be costly (human resources + time). Methods improving ATPG (Automatic Test Pattern Generation) are needed.

Requirements

Hand Made + ATPG +

Random Walk +…

Testing Sequences

9

Testing: Obstructions (2)

Testing is SLOW because to get a reasonable coverage we need to run many testing sequences. This is a problem when time-to-market is an issue (and for most product this IS an issue). Methods to speed up testing are needed.

System (Model)

Compute output by Simulation or by running the actual

system when possible

Input sequences

… u1(3) u1(2) u1(1) u1(0)

… un(3) un(2) un(1) un(0)

………………

Output sequences

y1(0) y1(1) y1(2) y1(3) …

………………

yn(0) yn(1) yn(2) yn(3) …

The value of n can easily be in the order of 106. Note that for each input sequence an output sequence has to be generated and checked for conformity.

10

Testing: Obstructions (3)Testing without automation tends to discover errors towards the end of the design flow. Error fixing is very expensive at that point and may delay product release. Methods to discover errors as soon as possible are needed.

0

5

10

15

20

25

30

35

40

1X 3-6X 10X 15-40X 30-70X 40-1000X

Without AutomatedtestingWith Automated testing

Early development Implementation

Number of times more expensive to fix

Err

ors

cau

ght

(per

cent

)

Source: Mercury Interactive, Siebel Siemens

11

Testing: Obstructions (4)

Presently more than 50% of the cost of the final product is testing, and this cost is growing up. Thus keeping low (no much more than 50%) the cost of testing is a key issue in a competitive market.

12

Testing: False NegativesTesting can only cover a SMALL part of the set of reachable system states. This may lead to false negatives (… unforseeable circumstances).

Typically corner cases (i.e. states that have a low probability of being reached) are not visited during testing.

Thus errors that have a low probability of showing up are hard (impossible) to detect using testing.

Unfortunately such low probability errors may be costly to fix at later design stages and/or their consequences can be very costly (Pentium 2 bug: billions of dollars …).

Moreover today complex designs are full of such cases …

13

Summing up

Speed up bug hunting (to decrease costs and time-to-market)

Improve coverage (to increase quality … and to decrease the probability of losing markets)

HOW ???

14

Automatic Verification Game

Given:a system Sys (e.g. hardware, software, hybrid, etc) and an specifications Spec for Sys (e.g. what Sys should or should not do)

Check automatically:If system Sys satisfies the given specifications Spec.

This is equivalent to run ALL possible testing sequences!!

15

Automatic Verification Game (2)

Spec: definition of what Sys should do and should not do using your beloved language (again) and/or your most favorite logic, e.g:

Temporal Logic (CTL, CTL*, …), First Order Logic, etc

Sys: definition of system under consideration using your beloved language, e.g.: VHDL, Verilog, SDL, StateCharts, C, C++, Java, MathLab, Simulink, …

16

Formal Verification via Model Checking

Model Checking is an automatic method for formal verification of Finite State Systems. Note that many hardware and/or software systems can be modeled as finite state systems.

The main goal of Formal Verification is to verify that a given system (hardware and/or software) meets its specifications. Thus formal verification is conceptually equivalent to testing with 100\% coverage.

Exhaustive testing is not feasible even for small systems.Thus verification methods rely on a suitable analysis of system definition and system specifications to produce their answers.

As a result formal verification, unlike testing, applies only to the system description. Testing also applies to the physical system (when it exists). Formal verification can be interactive or automatic.

17

Model Checking Dream

Model Checker(Equivalent to

Exhaustive testing)

Sys(VHDL, Verilog, C, C++

Java, MathLab, Simulink, …)

BAD(CTL, CTL*, LTL, …)

PASSFAILWhat went

wrong …

I.e. no sequence of events (states) can possibly lead to an undesired state.

CounterexampleI.e. sequence of events (states) leading to an undesired state.

18

Example (Model Checking) (1) x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

0

1 3

4

5

2

1

2

2

2

2


Spec FAIL

19

Example (Model Checking) (2) x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

2

0

1 3

4

5

2

1

21 1

11

1

2

2

2

2


Spec FAILSpec ok if u(t) = 0, 1.

20

A Larger Systemx(t + 1) = case x(t) – 2 + u(t) when x(t) + y(t) > 4

x(t) – 1 + u(t) when x(t) + y(t) = 4 x(t) + u(t) when x(t) + y(t) = 3 x(t) + 1 + u(t) when x(t) + y(t) = 2 x(t) + 2 + u(t) when x(t) + y(t) < 2 esac

y(t + 1) = u(t)u(t) = -1, 0, 1

0,0

1,-1

2,0

3,1

2,-1

3,0

4,1

3,-1

4,0

5,1

-1

0

1

x,y

21

Verification/TestingVerification, from system model Sys AND specifications Spec produces a sequence of stimuli (events) , if any, leading Sys to violate Spec. + faster than testing (good to improve time-to-market)+ gives full coverage (good to improve quality)+ early error detection (decreases costs)- is computationally VERY expensive (because of state explosion)

Testing, from system model Sys AND a sequence of stimuli (events) shows where leads (in | | steps).

+ is computationally inexpensive - many testing sequences may be needed to get good coverage- false negatives- late error detection

22

Transition Graph/Transition Relationx(t + 1) = f(x(t), u(t)) x’ = f(x, u)

x’ = if (u = 0) then (x + 1)mod3 else (x – 1)mod3; x(0) = 0; u = 0, 1

0 1 2u = 0

u = 1

u = 0

u = 1u = 0

u = 1

0 1

x

u

0, 10, 0 0, 2

1, 0 1, 1 1, 2

Transition Graph = Transition Relation u, x

23

Layman model checking usage

We show with a small running example (mutex) a typical “verification via model checking” layman session.

24

Mutual Exclusion (Mutex)n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

n1, n2, 1 t1, n2, 1 c1, n2, 1 n1, t2, 1 t1, t2, 1 c1, t2, 1

n1, c2, 1 t1, c2, 1 c1, c2, 1 n1, n2, 2 t1, n2, 2 c1, n2, 2

n1, t2, 2 t1, t2, 2 c1, t2, 2 n1, c2, 2 t1, c2, 2 c1, c2, 2

Mutual exclusion: AG (S1 != c1 | S2 != c2) … trueNegation of mutual exclusion: EF (S1 = c1 & S2 = c2) … falseNo starvation S1: AG (S1 = t1 --> AF (S1 = c1)) … trueNo starvation S2: AG (S2 = t2 --> AF (S2 = c2)) … trueState (t1, n2, *) reachable: AG (S1 != t1 | S2 != n2) … false

25

Mutex 2 (arbitrary initial state)

Mutual exclusion: AG (S1 != c1 | S2 != c2) …Negation of mutual exclusion: EF (S1 = c1 & S2 = c2) …No starvation S1: AG (S1 = t1 --> AF (S1 = c1)) …No starvation S2: AG (S2 = t2 --> AF (S2 = c2)) …

n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

26

SMV output (mutex 2)-- AG (S1 != c1 | S2 != c2) is false as demonstrated by the following execution sequence

state 1.1: S1 = c1 S2 = c2 turn = 2

-- EF (S1 = c1 & S2 = c2) is false

-- AG (S1 = t1 -> AF S1 = c1) is true

-- AG (S2 = t2 -> AF S2 = c2) is true

resources used:user time: 0.03 s, system time: 0.04 sBDD nodes allocated: 730Bytes allocated: 1245184BDD nodes representing transition relation: 31 + 6

27

Mutex 3 (~ arbitrary initial state)


n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

28

SMV output (mutex 3)-- specification AG (S1 != c1 | S2 != c2) is true

-- specification EF (S1 = c1 & S2 = c2) is false

-- specification AG (S1 = t1 -> AF S1 = c1) is true

-- specification AG (S2 = t2 -> AF S2 = c2) is true


29

Mutex 4 (with arbitrary delays)


n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

30

SMV output (mutex 4)

-- AG (S1 != c1 | S2 != c2) is true-- AG (S1 = t1 -> AF S1 = c1) is false-- as demonstrated by the following execution sequence

state 2.1: S1 = c1 S2 = n2 turn = 2state 2.2: S1 = n1 S2 = t2

-- loop starts here –state 2.3: S1 = t1 S2 = c2state 2.4:

n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

31

SMV output (mutex 4) … cntd-- AG (S2 = t2 -> AF S2 = c2) is false-- as demonstrated by the following execution sequence

state 3.1: S1 = c1 S2 = n2 turn = 2

-- loop starts here –

state 3.2: S2 = t2state 3.3:


32

SMV (mutex 4 + FAIRNESS)

FAIRNESS !(S1 = n1)FAIRNESS !(S1 = t1)FAIRNESS !(S1 = c1)FAIRNESS !(S2 = n2) FAIRNESS !(S2 = t2)FAIRNESS !(S2 = c2)SPEC AG((S1 != c1) | (S2 != c2))SPEC EF((S1 = c1) & (S2 = c2))SPEC AG((S1 = t1) -> AF (S1 = c1))SPEC AG((S2 = t2) -> AF (S2 = c2))

n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

33

SMV output (mutex 4 + FAIRNESS)

-- AG (state1 != c1 | state2 != c2) is true-- EF (state1 = c1 & state2 = c2) is false-- AG (state1 = t1 -> AF state1 = c1) is true-- AG (state2 = t2 -> AF state2 = c2) is trueresources used:user time: 0.03 s, system time: 0.04 sBDD nodes allocated: 615Bytes allocated: 1245184BDD nodes representing transition relation: 34 + 6

n1 t1

c1 S2=t

2 &

T=1

S2 =

n2

S1 n2 t2

c2 S1=t

1 &

T=2

S1 =

n1

S2

1 2T

S1=n1 & S2=t2

S2=n2 & S1=t1

34

A look under the hoodSys

(VHDL, Verilog, C, C++Java, MathLab, Simulink, …)

SpecE.g. CTL, CTL*, LTL, …

Check if it holds thatF(I, N ) is identically 1

Sys can be described by boolean functions:

initial states: I(x) = 1 iff x is an initial state of Sys

transition relation:N(x, x’) = 1 iff

there exists a transition from x to x’

From Spec we can define a function F from I, N to boolean values {0, 1}

s.t. F(I, N ) is identically 1

iff Spec is satisfied

35

Obstructions

Representation of Sys (i.e. (I, N)) may be too big (easily gigabytes … of RAM). Note: Sys transition graph can easily have more than 1020 nodes (state explosion).

Even if (I, N) is not too big we may run out of memory when checking if F(I, N) is identically 1.

The above obstructions cannot be eliminated. However there are algorithms that can actually mitigate them. Such algorithms are effective in many practical cases (… altough they are exponential with probability 1).

36

Model Checking as State Space Exploration

Given a Finite State System S = (S, I, Next), where:S : Finite set of states;I : set of initial states;Next : function mapping a state to the set of its successors;

Visit all states that SS can reach from I … in order to check if there is bad reachable state (i.e. a state that violates our specs).

For safety properties (i.e. no bad state is reachable) the model checking problem becomes the reachability problem on the transition graph of the system to be analyzed.

37

Model Checking FlavorsExplicit

Set Reach of visited states stored in a Hash Table.Explicit approach typically works well for protocols, hybrid systems and software-like systems (i.e. asynchronous systems).E.g.: SPIN (Bell Lab), Murphi (Stanford), COSPAN (Bell Lab)

SymbolicSet Reach of visited states represented with its characteristic function f. That is f(s) = if (s is in Reach) then 1 else 0.States are bit vectors, thus f is a Boolean function. Ordered Binary Decision Diagrams (OBDDs) are used to efficiently represent and manipulate f. Symbolic approach typically works well for Hardware-like systems(i.e. synchronous systems).E.g.: SMV (CMU), VIS (CU + Berkeley), CUDD (CU), FORTE (INTEL), SLAM (Microsoft), RuleBase (IBM).

38

Explicit State Space Exploration

From the system definition (e.g. given using VHDL or C) we get the following functions:

• Next(s) returning the set of successors of system state s;• Start() returning the set of initial states;• Inv(s) returning true iff state s satisfies the invariants (our spec).

With such functions we can define a State Space Exploration function.E.g. we can use a BFS (Breadth first Search) or a DFS (Depth First Search).

39

BFS

Hash_Table T;Queue Q;bfs(){ for each startstate s {insert(T, s); enqueue(Q, s)} while (Q is not empty) { s = dequeue(Q); check invariants for s; for all s’ in Next(s) if (s’ is not in T) /* fresh state */ {insert(T, s’); enqueue(Q, s’); } }}

Hash Table

T

s1

s2

s3

s

1. Get a new state s to expand from

queue

Que

ue Q

2. Check inv for s

3. If s1 (s2, s3) is not already in H, insert s1 (s2, s3) in H and Q.

System Transition

Graph

Visited states to be expanded

Visited states

Successors of state s

40

Example (BFS) (1)

x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

2

0

1 3

4

5

2

1

21 1

11

1

2

2

2

2

41

Example (BFS) (2) x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t), u(t) = 1, 2. x(0) = 0

0

1 3

4

5

2

1

2

2

2

2

42

Hash Compaction

States may take hundreds of bytes. To save on RAM we can store in T just state signatures h(s). Usually a state signature takes 5 bytes or so.It can be proved that the omission probability is very low.

011000111001010101010101100001111111001010101010101010101010101010101

001010101001000010101000

Hash Compaction

43

Caching

To save even more RAM we can forget some of the state signatures in hash table T.Experimental results show that we can forget about 50% of the states in T and still get termination. This work because protocol transitions are local.

Hash Table T

01101010101010000000011111111

Hash Table T

000000011111111

Collision Previously stored state forgot

Danger: we may revisit the same state forever and ever: no termination!!

44

Locality

0 1 2 3 4

1

1

1

1

-4

0

0

-1

-1

-1

1

0

1

-2

Transition k-local iff|level(s’) – level(s)| <= k

K-transition iff level(s’) – level(s) = K

45

Locality

Our experimental results show that:

For all protocol like systems, for most states, most transitions (typically more than 75%) are 1-local.

46

State SamplingLet d(s, k) be the fraction of transitions from state s that are k-transitions.

Thus d(s, k) is the probability of getting a k-transition when picking at random a transition from state s.

Consider the experiment of selecting at random a state s and then returning d(s, k). In this way we get a random variable that we denote with d(k).

The expected value of d(k) is the average value of d(s, k) on all reachable states.

s

47

Experimental Evidence of Locality

Protocol E{d(-1)} dev(-1) E{d(0)} dev(0) E{d(1)} dev(1) Sum Avgn_peterson.m 0 0 0 0 0,958174 0,087772 0,958174adash.m 0,038178 0,122 0,005581 0,043607 0,723393 0,292406 0,767152adashbug.m * 0,03766 0,124403 0,002289 0,029503 0,793586 0,270018 0,833535eadash.m 0,050598 0,096015 0,015647 0,056255 0,765236 0,178076 0,831481ldash.m 0,010726 0,071917 0,076359 0,138464 0,624139 0,191624 0,711224arbiter.m * 0,008489 0,057543 0,010737 0,053714 0,92784 0,168859 0,947066cache3.m 0,040121 0,178884 0,004766 0,055844 0,565482 0,381654 0,610369cache3multi.m 0,038984 0,102299 0,002991 0,026349 0,831139 0,176004 0,873114newcache3.m 0,036034 0,099187 0,009121 0,053342 0,736229 0,227796 0,781384sym.cache3.m 0,041675 0,10478 0,00757 0,044577 0,876884 0,17786 0,926129down.m * 0 0 0,077639 0,142608 0,922361 0,142608 1kerb.m 0 0 0,18417 0,385163 0,441651 0,494666 0,625821list6.m 0,018367 0,071081 0,024625 0,081523 0,844018 0,189053 0,88701list6too.m 0 0 0 0 0,988378 0,06214 0,988378newlist6.m 1,53E-05 0,001751 0 0 0,999586 0,00909 0,9996mcslock1.m 0,012886 0,067574 0 0 0,881379 0,162002 0,894265mcslock2.m 0,005465 0,045815 0,000564 0,015111 0,921489 0,156949 0,927518ns-old.m 0,546833 0,497802 0 0 0,101695 0,302247 0,648528ns.m 0,585714 0,492598 0 0 0,096939 0,295874 0,682653sci.m 0,215646 0,238654 0,010819 0,061719 0,642466 0,265885 0,868931

48

Symbolic Model CheckingSet of initial states represented with a boolean function I s.t.:

I(x) = 1 iff x is an initial state.

Transition graph represented with transition relation, i.e. a boolean function N s.t.:

N(x, x’) = 1 iff there is a transition from x to x’

x x’

Reachable states: least solution to the following (functional) fixpoint equation (unknown: R)

R(x) = I(x) E y [R(y) N(y, x)]

49

Computing the set of reachable states

Problem: how do we solve equationR(x) = I(x) E y [R(y) N(y, x)]

Answer (classical):

R(0)(x) = 0R(k + 1)(x) = I(x) E y [R(k)(y) N(y, x)], k = 0, 1, 2…

Stop when R(k + 1) = R(k) This eventually happens …

Obstructions:Efficient manipulation of boolean functionsEfficient check of functional equality

50

Ordered Binary Decision Diagrams (OBDDs: an efficient representation for boolean functions)

1 1 1

2

1 0

1

0

11

1

0 0

0

x1 x2 x1 x2 x2

x1

51

OBDDs 2

OBDDs represent f(x1, … xn) in a canonical way once an ordering on the variable x1, … xn is given.

Equality test O(1).

If_then_else(F, G, H) computable in O(max(|F|, |G|, |H|)).

OBDDs often compact on boolean functions occurring in practice (isotropic boolean functions).

OBDDs representation of randomly selected n-ary boolena function has size exponential in n with probability 1.

52

Bounded Model Checking

FAILk = E x0 x1 … xk [I(x0) R(x0, x1) R(x1, x2) … R(xk - 1, xk) ERROR(xk)]

To reduce complexity lets just check if a state reachable in k steps is an error state.

x0 x1 x2 xk

R(x0, x1) R(x1, x2) R(xk - 1, xk)

This is SATisfiability, i.e. given a boolean expression F(z) find an assignment z to z s.t. F(z) = 1. ,

In our case F(x0, x1, … , xk ) =[I(x0) R(x0, x1) R(x1, x2) … R(xk - 1, xk) ERROR(xk)].

. . .I(x0)

ERROR(xk)

53

Status

The sketched automatic verification algorithms can be used for

• Requirements/Spec Validation• Protocol Verification• Digital Hardware Verification• Embedded Software Verification

There are many cases in which digital devices (hardware and/or software) interact with the physical environment. In such cases the environment continuous dynamics must be taken into account.

54

Hybrid SystemsHybrid Systems are systems with discrete as well as continuous state variables. Typically requirements analysis for embedded software/hardware leads to study verification of hybrid systems.

Examples of hybrid systems:

• Industrial Plants• Automotive systems (cost of software in new cars compares with that of the mechanics)• Avionics• Biological models•…

55

Model Checking a Turbogas

We sketch how model checking can be used for hybrid systems analysis by showing its usage for automatic verification of the Turbogas Control System of a 2MW Co-generative Power Plant (ICARO).

56

Gas Turbine System

ControllerGas Turbine(Turbogas)

Disturbances: electric users, param. var, etc

Vrot: Turbine Rotation speedTexh: Exhaust smokes TemperaturePel: Generated Electric PowerPmc: Compressor Pressure

Settings Fuel Valve OpeningFG102

Vrot, Texh, Pel, Pmc

57

Controller

MIN ADJ

Offset

Valve FG102 Opening Command

12MW

N1Gov

PowLim

ExTLim

Winner

Vrot

Pel

Pmc

Texh

Limiter

Vrot: Turbine Rotation speed

Texh: Exhaust smokes Temperature

Pel: Generated Electric Power

Pmc: Compressor Pressure

58

Power Limiter (PowLim)Electric Power Controller

Pel Setpoint (+2MW)

Winner

OutputPowLim

PelS

P

Celli = “Power Limiter”A = 3000kWB = 10Mw





59

N1 Governor (N1Gov)Turbine Rotation Speed Controller

1/s

XS

P

Accelleration

Deceleration

Pel

Kdr

network

Vrot

-

+Output N1 Governor

105%

Winner

Celli = “N1 Governor”A = 0B = 10MW

isle

6%





60

Exhaust Temperature Limiter(ExTLim)

Exhaust Smoke Temperature Controller

+Pmc

Offset

P

S

Winner

TexhCelli = “Exhaust Temperature Limiter”A = 0B = 10MW

Output Exhaust Temperature Limiter





61

Cell i

+

1/s

X

X

AND

+

-

S

P

>0? Reset at u + 4kWu = min(output N1Gov, output PowLim, output ExTLim)

-

CellOutput

Kp

Ki

Winner != i?

Winner name

-10MW

10MW

B

A

A B

SAT

SAT

62

Gas Turbine

Gas Turbine

FG102 Texh

Vrot

Pel

Disturbances: el. users, par. var, etc.





63

PLAN

• Build discrete time model of ICARO Turbogas Control System.

• Code system model with Murphi verifier. This is very similar to simulation code, only more abstract because of

model checking limitations (state explosion).

• Run verification experiments.

64

Experimental ResultsMAX_D_U

(KW/sec)

Reachable States

Rules Fired

Diameter CPU (sec) Result

1000 2,246,328 6,738,984 12904 16988.18 PASS

1750 7,492,389 22,477,167 7423 54012.18 PASS

2500 1,739,719 5,186,047 1533 12548.25 FAIL

5000 36,801 109,015 804 271.77 FAIL

Results on a INTEL Pentium 4, 2GHz Linux PC with 512 MB RAM. Murphi options: -b, -c, --cache, -m350

65

Fail trace: MAX_D_U = 2500 KW/sec10 ms time step (100 Hz sampling frequency)

Electric user demand (KW)

Rotation speed (percentage of max = 22500 rpm)

Allowed range for rotation speed:40-120

66

Fail trace: MAX_D_U = 5000 Kw/sec10 ms time step (100 Hz sampling frequency)

Electric user demand (KW)

Rotation speed (percentage of max = 22500 rpm)

Allowed range for rotation speed:40-120

67

Probabilistic Model Checking (1)Sometimes we can associate a probability with each transition. In such cases reachability analysis becomes the task of computing the stationary distribution of a Markov Chain. This can be done using a Probabilistic Model Checker (state space too big for matrices).

0

1

2

0.4

0.6

0.3

0.7

0.8

0.2

68

User Demand Distribution

Where: M = max user demand (MAX_U), a = speed of variation of user demand (MAX_D_U)

0.4 + b*(v – M)*|v – M| /M2 when i = 1p(v, i) = 0.2 when i = 0 0.4 + b*(M - v)*|M - v| /M2 when i = -1-0.4 <= b <= 0.4

Let u(t) be the user demand at time t. We can define the (stochastic) dynamics of the user demand as follows:

min(u(t) + a, M) with probability p(u(t), 1)u(t + 1) = u(t) with probability p(u(t), 0) max(u(t) - a, 0) with probability p(u(t), -1)

The further u(t) from u0 (nominal user demand) the higher u(t) probability to return towards u0. That is to decrease when u(t) > u0, to increase when u(t) < u0.

69

Finite Horizon Markov Chain Analysis… of our turbogas

MAX_D_U

(KW/sec)

Visited States

Rules

Fired

Horizon CPU time (s) Probability of violating spec

2500 3,018,970 8,971,839 1600 68562 7.373292e-05

3500 2,226,036 6,602,763 1400 50263 1.076644e-04

4500 1,834,684 5,439,327 1300 41403 9.957147e-05

5000 83,189 246,285 900 2212 3.984375e-03

70

ConclusionsNonwithstanding state explosion, Automatic Verification (reachability analysis) is a very useful tool for design and analysis of complex systems such as: digital hardware, software and hybrid systems.

Decrease the probability of leaving undetected bugs in our design, thus increasing design quality.

Speed up the testing/simulation process, thus decreasing costs and time-to-market.

Early error detection, thus decreasing design costs.

Support exploration of more complex, hopefully more efficient, solutions by supporting their debugging.

Automatic Verification allows us to:

Future work: fight state explosion to make possible verification of larger systems.Directions: automatic model abstraction, better algorithms and data structures for SAT, statistical properties of transition graphs, …Extend usage: … to anyone needing reachability analysis of beloved system.

Documents

FATAL ERROR: Evento Imprevedibile … o no