Transcript Exploiting Transition Locality in Automatic Verification

FATAL ERROR:
Evento Imprevedibile … o no
Enrico Tronci
Dipartimento 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
This program has executed an illegal
operation and will be terminated
Error code: 56
Press any key to restart your system
2
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.
3
Examples
This program has executed an illegal
operation and will be terminated
Error code: 56
… is an undesired state for
Windows XX
Press any key to restart your system
1.1
= 3.7
1.1
… 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, …
4
An approximate answer
BUG HUNTING: Testing + Simulation
Input sequence
(stimulus)
Output sequence
System (Model)
… u(3) u(2) u(1) u(0)
y(0) y(1) y(2) y(3) …
Compute output by
Simulation or by running the actual
system when possible
Define initial state + parameters
Observer
checks that output sequence ok
5
Example (Testing 1)
x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t),
2
1
0
1
u(t) = 1, 2.
3
1
1
2
1
x(0) = 0
1
2
2
4
2
2
Spec: x(t) < 5.
I.e. no state with x(t) >= 5
is reachable.
Sim length: 10
1, 2, 1, 2, 1, 1, 2, 2, 2, 1
Spec does not fail on this run
6
Example (Testing 2)
x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t),
1
u(t) = 1, 2.
3
2
2
0
1
x(0) = 0
1
1
5
2
4
2
Spec: x(t) < 5.
I.e. no state with x(t) >= 5
is reachable.
Sim length: 6
1, 2, 1, 2, 1, 2
Spec FAIL
7
Testing: Obstructions (1)
Generation of targeted testing sequences can be costly (human
resources + time). Methods improving ATPG (Automatic Test
Pattern Generation) are needed.
Hand Made +
ATPG +
Random Walk +
…
Testing Sequences
8
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-tomarket is an issue (and for most product this IS an issue).
Methods to speed up testing are needed.
Input sequences
… u1(3) u1(2) u1(1) u1(0)
………………
… un(3) un(2) un(1) un(0)
System (Model)
Compute output by
Simulation or by running the actual
system when possible
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.
9
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.
Without Automated
40
testing
35
With Automated testing
30
25
Source:
Mercury Interactive,
Siebel Siemens
20
15
10
5
0
1X
Early development
3-6X
10X
15-40X
30-70X
401000X
Number of times more
expensive to fix
Implementation
10
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.
11
Testing: False Negatives
Testing 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 …
12
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 ???
13
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!!
14
Automatic Verification Game (2)
Sys: definition of system under consideration using
your beloved language, e.g.: VHDL, Verilog, SDL,
StateCharts, C, C++, Java, MathLab, Simulink, …
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
15
Formal Verification via Model Checking
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.
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.
16
Model Checking Dream
Sys
(VHDL, Verilog, C, C++
Java, MathLab, Simulink, …)
BAD
(CTL, CTL*, LTL, …)
Model Checker
(Equivalent to
Exhaustive testing)
FAIL
Counterexample
I.e. sequence of events
(states) leading to an
undesired state.
PASS
I.e. no sequence of
events (states) can
possibly lead to an
undesired state.
17
Example (Model Checking) (1)
x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t),
1
u(t) = 1, 2.
3
2
0
1
x(0) = 0
2
5
2
2
Spec: x(t) < 5.
I.e. no state with x(t) >= 5
is reachable.
2
4
Spec FAIL
18
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
1
3
2
2
0
1
1
1
1
5
1
2
1
2
2
4
2
Spec: x(t) < 5.
I.e. no state with x(t) >= 5
is reachable.
Spec FAIL
Spec ok if u(t) = 0, 1.
19
A Larger System
x(t + 1) = case
x(t) – 2 + u(t)
x(t) – 1 + u(t)
x(t) + u(t)
x(t) + 1 + u(t)
x(t) + 2 + u(t)
-1 1,-1
0
0,0
1
when x(t) + y(t) > 4
when x(t) + y(t) = 4
when x(t) + y(t) = 3
when x(t) + y(t) = 2
when x(t) + y(t) < 2
y(t + 1) = u(t)
u(t) = -1, 0, 1
esac
2,-1
3,-1
2,0
3,0
4,0
3,1
4,1
5,1
x,y
20
Verification/Testing
Verification, from system model Sys AND specifications Spec
produces a sequence of stimuli (events) j, 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) j shows where j leads (in | j | steps).
+ is computationally inexpensive
- many testing sequences may be needed to get good coverage
- false negatives
- late error detection
21
Transition Graph/Transition Relation
x’ = f(x, u)
x(t + 1) = f(x(t), u(t))
x’ = if (u = 0) then (x + 1)mod3 else (x – 1)mod3;
u=1
u=0
0
1
u=1
x(0) = 0;
u = 0, 1
u=0
u=1
x
2
u=0
0
u
1
Transition Graph = Transition Relation
0, 0
0, 1
1, 0
1, 1
u, x
0, 2
1, 2
22
Layman model checking usage
We show with a small running example (mutex) a typical
“verification via model checking” layman session.
23
Mutual Exclusion (Mutex)
n1
S1
t1
S2
n2
S1=n1 & S2=t2
t2
1
c1
T
2
S2=n2 & S1=t1
c2
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:
Negation of mutual exclusion:
No starvation S1:
No starvation S2:
State (t1, n2, *) reachable:
AG (S1 != c1 | S2 != c2)
EF (S1 = c1 & S2 = c2)
AG (S1 = t1 --> AF (S1 = c1))
AG (S2 = t2 --> AF (S2 = c2))
AG (S1 != t1 | S2 != n2)
… true
… false
… true
… true
… false
24
Mutex 2 (arbitrary initial state)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
Mutual exclusion:
Negation of mutual exclusion:
No starvation S1:
No starvation S2:
c2
T
2
S2=n2 & S1=t1
AG (S1 != c1 | S2 != c2)
EF (S1 = c1 & S2 = c2)
AG (S1 = t1 --> AF (S1 = c1))
AG (S2 = t2 --> AF (S2 = c2))
…
…
…
…
25
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 s
BDD nodes allocated: 730
Bytes allocated: 1245184
BDD nodes representing transition relation: 31 + 6
26
Mutex 3 (~ arbitrary initial state)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
Mutual exclusion:
Negation of mutual exclusion:
No starvation S1:
No starvation S2:
c2
T
2
S2=n2 & S1=t1
AG (S1 != c1 | S2 != c2)
EF (S1 = c1 & S2 = c2)
AG (S1 = t1 --> AF (S1 = c1))
AG (S2 = t2 --> AF (S2 = c2))
…
…
…
…
27
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
resources used:
user time: 0.02 s,
system time: 0.04 s
BDD nodes allocated: 635
Bytes allocated: 1245184
BDD nodes representing transition relation: 31 + 6
28
Mutex 4 (with arbitrary delays)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
Mutual exclusion:
Negation of mutual exclusion:
No starvation S1:
No starvation S2:
c2
T
2
S2=n2 & S1=t1
AG (S1 != c1 | S2 != c2)
EF (S1 = c1 & S2 = c2)
AG (S1 = t1 --> AF (S1 = c1))
AG (S2 = t2 --> AF (S2 = c2))
…
…
…
…
29
SMV output (mutex 4)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
T
2
S2=n2 & S1=t1
c2
-- 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
state 2.2: S1 = n1
S2 = n2
S2 = t2
-- loop starts here –
state 2.3: S1 = t1 S2 = c2
state 2.4:
turn = 2
30
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 = t2
state 3.3:
resources used:
user time: 0.03 s,
system time: 0.04 s
BDD nodes allocated: 799
Bytes allocated: 1245184
BDD nodes representing transition relation: 34 + 6
31
SMV (mutex 4 + FAIRNESS)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
c2
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))
T
2
S2=n2 & S1=t1
32
SMV output (mutex 4 + FAIRNESS)
n1
S1
t1
n2
S2
S1=n1 & S2=t2
t2
1
c1
c2
T
2
S2=n2 & S1=t1
-- 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 true
resources used:
user time: 0.03 s,
system time: 0.04 s
BDD nodes allocated: 615
Bytes allocated: 1245184
BDD nodes representing transition relation: 34 + 6
33
A look under the hood
Sys
Spec
(VHDL, Verilog, C, C++
Java, MathLab, Simulink, …)
E.g. CTL, CTL*, LTL, …
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
Check if it holds that
F(I, N ) is identically 1
34
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).
35
Model Checking as
State Space Exploration
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.
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 S can reach from I … in order to check if there is bad
reachable state (i.e. a state that violates our specs).
36
Model Checking Flavors
Explicit
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)
Symbolic
Set 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).
37
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).
38
Hash
Table
T
Visited states
to be expanded
Queue Q
Visited states
BFS
s1
1. Get a new state s
to expand from
queue
2. Check inv for s
s
3. If s1 (s2, s3) is not already in H,
insert s1 (s2, s3) in H and Q.
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’); }
}}
s2
s3
Successors of
state s
39
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
1
3
2
2
0
1
1
1
1
5
1
2
1
2
2
4
2
40
Example (BFS) (2)
x(t + 1) = if x(t) <= 3 then x(t) + u(t) else x(t) – u(t),
1
3
2
0
1
u(t) = 1, 2.
x(0) = 0
2
5
2
2
2
4
41
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
Hash Compaction
001010101001000010101000
42
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.
Previously stored state forgot
Collision
000000011111111
01101010101010
000000011111111
Hash Table T
Hash Table T
Danger: we may revisit the same state forever and ever: no termination!!
43
Locality
K-transition iff
Transition k-local iff
|level(s’) – level(s)| <= k
level(s’) – level(s) = K
-4
1
-2
0
1
1
0
-1
0 -1
1
1
-1
0
1
1
2
3
4
44
Locality
Our experimental results show that:
For all protocol like systems, for most states, most
transitions (typically more than 75%) are 1-local.
45
State Sampling
Let 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
46
Experimental Evidence of Locality
Protocol
n_peterson.m
adash.m
adashbug.m *
eadash.m
ldash.m
arbiter.m *
cache3.m
cache3multi.m
newcache3.m
sym.cache3.m
down.m *
kerb.m
list6.m
list6too.m
newlist6.m
mcslock1.m
mcslock2.m
ns-old.m
ns.m
sci.m
E{d(-1)}
0
0,038178
0,03766
0,050598
0,010726
0,008489
0,040121
0,038984
0,036034
0,041675
0
0
0,018367
0
1,53E-05
0,012886
0,005465
0,546833
0,585714
0,215646
dev(-1)
0
0,122
0,124403
0,096015
0,071917
0,057543
0,178884
0,102299
0,099187
0,10478
0
0
0,071081
0
0,001751
0,067574
0,045815
0,497802
0,492598
0,238654
E{d(0)}
0
0,005581
0,002289
0,015647
0,076359
0,010737
0,004766
0,002991
0,009121
0,00757
0,077639
0,18417
0,024625
0
0
0
0,000564
0
0
0,010819
dev(0)
0
0,043607
0,029503
0,056255
0,138464
0,053714
0,055844
0,026349
0,053342
0,044577
0,142608
0,385163
0,081523
0
0
0
0,015111
0
0
0,061719
E{d(1)}
0,958174
0,723393
0,793586
0,765236
0,624139
0,92784
0,565482
0,831139
0,736229
0,876884
0,922361
0,441651
0,844018
0,988378
0,999586
0,881379
0,921489
0,101695
0,096939
0,642466
dev(1)
0,087772
0,292406
0,270018
0,178076
0,191624
0,168859
0,381654
0,176004
0,227796
0,17786
0,142608
0,494666
0,189053
0,06214
0,00909
0,162002
0,156949
0,302247
0,295874
0,265885
Sum Avg
0,958174
0,767152
0,833535
0,831481
0,711224
0,947066
0,610369
0,873114
0,781384
0,926129
1
0,625821
0,88701
0,988378
0,9996
0,894265
0,927518
0,648528
0,682653
0,868931
47
Symbolic Model Checking
Set 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’
Reachable states: least solution to the following (functional) fixpoint
equation (unknown: R)
R(x) = I(x)  E y [R(y)  N(y, x)]
x
x’
48
Computing the set of reachable states
Problem: how do we solve equation
R(x) = I(x)  E y [R(y)  N(y, x)]
Answer (classical):
R(0)(x) = 0
R(k + 1)(x) = I(x)  E y [R(k)(y)  N(y, x)],
Stop when R(k + 1) = R(k)
k = 0, 1, 2…
This eventually happens …
Obstructions:
Efficient manipulation of boolean functions
Efficient check of functional equality
49
Ordered Binary Decision Diagrams
(OBDDs: an efficient representation for boolean functions)
x1  x2
x1  x2
x2
1
1
x1
1
0
0
0
1
1
1
1
1
2
0
0
50
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.
51
Bounded Model Checking
To reduce complexity lets just check if a state reachable in k steps is an
error state.
R(x1, x2)
R(x0, x1)
I(x0)
x0
x1
R(xk - 1, xk)
x2
...
ERROR(xk)
xk
FAILk = E x0 x1 … xk
[I(x0)  R(x0, x1)  R(x1, x2)  … R(xk - 1, xk)  ERROR(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)].
52
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.
53
Hybrid Systems
Hybrid 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
•…
54
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).
55
Gas Turbine System
Disturbances: electric users, param. var, etc
Settings
Fuel Valve
Opening
FG102
Gas Turbine
(Turbogas)
Controller
Vrot, Texh, Pel, Pmc
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Pel: Generated Electric Power
Pmc: Compressor Pressure
56
Controller
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Vrot
Pel: Generated Electric Power
N1Gov
Pmc: Compressor Pressure
Offset
Pel
12MW
PowLim
ADJ
MIN
Limiter
Winner
Texh
Pmc
ExTLim
Valve FG102
Opening Command
57
Power Limiter (PowLim)
Electric Power Controller
Pel Setpoint (+2MW)
S
Pel
P
Winner
Cell
i = “Power Limiter”
A = 3000kW
B = 10Mw
Output
PowLim
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Pel: Generated Electric Power
Pmc: Compressor Pressure
58
N1 Governor (N1Gov)
Turbine Rotation Speed Controller
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Pel: Generated Electric Power
Accelleration
Pmc: Compressor Pressure
105%
1/s
Deceleration
Pel
6%
X
network
+
Kdr
Output
N1 Governor
S
isle
Vrot
P
Cell
i = “N1 Governor”
A=0
B = 10MW
Winner
59
Exhaust Temperature Limiter
(ExTLim)
Exhaust Smoke Temperature Controller
Texh
P
Pmc
+
Offset
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Pel: Generated Electric Power
Pmc: Compressor Pressure
S
Cell
i = “Exhaust
Temperature Limiter”
A=0
B = 10MW
Winner
Output
Exhaust
Temperature
Limiter
60
Cell i
Kp
S
10MW
+
X
-10MW
-
+
SAT
Ki
P
B
1/s
X
SAT
A
A
Winner
name
Cell
Output
>0?
Winner != i?
AND
B
Reset at u + 4kW
u = min(
output N1Gov,
output PowLim,
output ExTLim)
61
Gas Turbine
Disturbances: el. users, par. var, etc.
Texh
FG102
Gas Turbine
Vrot
Pel
Vrot: Turbine Rotation speed
Texh: Exhaust smokes Temperature
Pel: Generated Electric Power
Pmc: Compressor Pressure
62
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.
63
Experimental Results
MAX_D_U Reachable Rules
States
Fired
(KW/sec)
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
64
Fail trace: MAX_D_U = 2500 KW/sec
10 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
65
Fail trace: MAX_D_U = 5000 Kw/sec
10 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
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.4
1
0.3
0
0.7
0.2
0.8
0.6
2
67
User Demand Distribution
Let u(t) be the user demand at time t. We can define the (stochastic) dynamics of
the user demand as follows:
u(t + 1) =
min(u(t) + a, M)
u(t)
max(u(t) - a, 0)
with probability p(u(t), 1)
with probability p(u(t), 0)
with probability p(u(t), -1)
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
p(v, i) = 0.2
0.4 + b*(M - v)*|M - v| /M2
-0.4 <= b <= 0.4
when i = 1
when i = 0
when i = -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.
68
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
69
Conclusions
Nonwithstanding 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.
Automatic Verification allows us to:
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.
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. 70