Verifica Automatica via Model Checking

1
Verifica Automatica via Model Checking

• Enrico Tronci
• Dipartimento di Informatica, Università di Roma
  La Sapienza,
• Via Salaraia 113, 00198 Roma, Italy,
• tronci_at_di.uniroma1.it
  http//www.dsi.uniroma1.it/tronci

May 2006
2
TRAMP

• Verification Goals. Give evidence of the
  following
• The interaction between the system (trains,
  vehiecles, etc), the communication
  infrastructure (TLC), the control policies in the
  DSS and the Operator never bring the system to an
  UNSAFE state
• The system efficiency is not decreased (is
  increased) by the supervisory control proposed by
  the project.

Get measures (with delay, noise, lost, etc).
Compute system state and action
Measures
System
DSS Operator Policy
Communication Channel
Send Command, according to policy
Get commnad (with delay, noise, lost, etc)
3
Model Checking Game
Sys (VHDL, Verilog, C, C Java, MathLab,
Simulink, UML )
BAD (CTL, CTL, LTL, PSL, )
Model Checker (Equivalent to Exhaustive testing)
PASS
FAIL
I.e. no sequence of events (states) can possibly
lead to an undesired state.
What went wrong
Counterexample I.e. sequence of events (states)
leading to an undesired state.
4
Examples
A few exmples from different domains to
illustrate the appraoch
5
A Control System
Disturbances electric users, param. var, etc
Settings
Fuel Valve Opening FG102
Controller
Gas Turbine (Turbogas)
Vrot, Texh, Pel, Pmc
Vrot Turbine Rotation speed Texh Exhaust smokes
Temperature Pel Generated Electric Power Pmc
Compressor Pressure
6
Experimental Results
MAX_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
7
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
8
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
9
Example
Low System (e.g. public info)
High System (e.g. private info)
NRL PUMP
Statistically modulated ACK
ACK
Buffer
LS
HS
Data
Data
The NRL Pump is a special purpose-device that
forwards data from a low (security) level system
LS to a high (security) level system HS, but not
conversely. Idea LS ACK delay is
probabilistically based on a moving average of HS
ACK delays.
NRL Pump (Probabilistic) Properties
LS
HS
Ready to send
Ready to receive
Minimize information flow from HS to LS.
Read Data
Got ACK
Send Data
Send ACK
Enforce reasonable performances, i.e.
ltaverage ACK delay as seen from LSgt ltaverage
HS ACK delaygt
Waiting ACK
Done
10
Covert Channel Experimental Results (1)
Pdec(h) probability of making a decision within
h time units. Pwrong(h) probability of making
the wrong decision within h time units We can
compute the probability of making the right
decision within h time units as Pright(h)
Pdec(h)(1 - Pwrong(h)). Of course we want
Pright(h) to be small. We studied the previous
probabilities for various settings of our model
parameters. BUFFER SIZE 3 5 WINDOW SIZE 3 5 OBS
WINDOW SIZE 3 5 About 2 days of computation for
each setting on a 2GHz Intel Pentium PC with
Linux OS and 512MB of RAM).
11
Covert Channel Exp Pdec, Pwrong as a function
of the number of steps h
12
Covert Channel Exp Pright as a Function of the
number of steps h
Our time unit is about the time needed to
transfer messages from/to the pump (about
1ms). Our experimental results show that the
high system can send bits to the low system at a
rate of about 1 bit every 10 seconds, i.e. 0.1
bits/sec. This is secure enough for many
applications.
13
Reliability AnalysisProbabilistic 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).
1
0.4
0.3
0
0.7
0.2
0.8
2
0.6
14
A Control System
Disturbances electric users, param. var, etc
Settings
Fuel Valve Opening FG102
Controller
Gas Turbine (Turbogas)
Vrot, Texh, Pel, Pmc
Vrot Turbine Rotation speed Texh Exhaust smokes
Temperature Pel Generated Electric Power Pmc
Compressor Pressure
15
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 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)
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 1 p(v, i)
0.2
when i 0 0.4 b(M - v)M
- v /M2 when i -1 -0.4 lt b lt 0.4
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) gt u0, to increase
when u(t) lt u0.
16
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
17
Mutual Exclusion (Mutex)
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
SPEC Mutual exclusion AG
(S1 ! c1 S2 ! c2) true No
starvation S1 AG (S1
t1 --gt AF (S1 c1)) true
18
Mutex ( arbitrary initial state)
Mutual exclusion AG (S1
! c1 S2 ! c2) No starvation
S1 AG (S1 t1 --gt AF
(S1 c1))
19
SMV output (mutex)
-- specification AG (S1 ! c1 S2 ! c2) is
true -- specification AG (S1 t1 -gt AF S1 c1)
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
20
Research Activity
Algorithms and Tools for

• Automatic Verification and Validation (Model
  Checking) of Hardwware systems SMV, VIS, BMC.
• Automatic Verification and Validation of
  Protocols and Software Systems Murphi, SPIN.
• Automatic Requirements Validation (via Model
  Checking)
• Automatic Verification of Hybrid Systems Murphi,
  Hytech.
• Automatic Verification of Probabilistic Systems
  (Reliability Analysis) PRISM, FHP-Murphi.
• Covert Channel Analysis, Security Analysis
  FHP-Murphi
• Automatic Synthesis of Optimal (Supervisory)
  Controllers for Finite State Systems.
• Optimization of Complex Systems (via Mixed
  Integer Linear Programming and SAT)
• Planning (via Model Checking).
• Datamining

Core Algorithms Graph Exploration, SAT, PLI,
OBDDS
21
Research Activity (2)
Algorithms and Tools for

• WIP Automatic Synthesis of Controllers for PCM
  systems (e.g. DC-DC converters, digital
  amplifiers, etc.).
• WIP Automatic Design and Verification of
  Autonomous Systems.

22
TOOLS http//www.dsi.uniroma1.it/tronci/cached.mu
rphi.html
Caching Murphi (Cmurphi) (also http//www.stanford
.edu/) Cmurphi (Rome La Sapienza, LAquila) is
a disk based extension of the Stanford Murphi
Verifier. Cmurphi has been used with success by
INTEL to verify Cache Coherence Protocols that,
because of state explosion, was not possible to
verify using Murphi.
FHP-Murphi FHP-Murphi allows Finite Horizon
Analysis of Markov Chains modelling stochastic
hybrids systems. Unlike PRISM, FHP-Murphi can
handle real numbers.
23
Automatic Verification A Money Saver
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.
Source Mercury Interactive, Siebel Siemens
Errors caught (percent)
Number of times more expensive to fix
Early development
Implementation
24
Open Source Model Checkers
Here are a few examples of open source model
checkers.
SMV, NuSMV (Carnegie Mellon University, IRST)
smv,VHDL / CTL SPIN (Bell Labs)
PROMELA
(C like)/ LTL Murphi (Stanford, Roma La
Sapienza, LAquila) Pascal like/assert()
style VIS (Berkeley, Stanford, Colorado
University) BLIF, Verilog/CTL, LTL PVS
(Stanford) PVS/PVS TVLA (Tel-Aviv) TVLA
/TVLA Java PathFinder (NASA) Java
Bytecode/LTL BLAST (Berkeley) C/assert()
25
Java Verification (BANDERA)SAnToS Group at
Kansas State University
26
Some Commercial Model Checkers
Here are a few examples of commercial model
checkers.
Cadence (Verilog, VHDL) Synopsis (Verilog,
VHDL) Innologic (Verilog) Telelogic (inside SDL
suite) Esterel Coverity (C, C)
27
In House Model Checkers
Here are a few examples of in house model
checkers.
FORTE (INTEL) Verilog, VHDL/Temporal
Logic SLAM (Microsoft) C/assert() BEBOP
(Microsoft) C/assert() Rule Based
(IBM) Verilog, VHDL/CTL, LTL CANVAS (IBM)
Java/constraints-guarantees Verisoft (Bell
Labs) C/C
28
Summing Up
Automatic Verification (reachability analysis) is
a very useful tool for design and analysis of
complex systems such as digital hardware,
embedded 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.