Verifica Automatica via Model Checking Enrico Tronci Dipartimento

Verifica Automatica via Model Checking Enrico Tronci Dipartimento di Informatica, Università di Roma “La Sapienza”, Via Salaraia 113, 00198 Roma, Italy, tronci@di. uniroma 1. it http: //www. dsi. uniroma 1. it/~tronci May 2006

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). Measures System DSS + Operator + Policy Communication Channel Get commnad (with delay, noise, lost, etc) Compute system state and action Send Command, according to policy 2

Model Checking Game Sys (VHDL, Verilog, C, C++ Java, Math. Lab, Simulink, UML …) BAD (CTL, CTL*, LTL, PSL, …) Model Checker (Equivalent to Exhaustive testing) t wen at Wh ng … wro 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. 3

Examples A few exmples from different domains to illustrate the appraoch 4

A Control System Disturbances: electric users, param. var, etc Settings Fuel Valve Opening FG 102 Gas Turbine (Turbogas) Controller Vrot, Texh, Pel, Pmc Vrot: Turbine Rotation speed Texh: Exhaust smokes Temperature Pel: Generated Electric Power Pmc: Compressor Pressure 5

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, 2 GHz Linux PC with 512 MB RAM. Murphi options: -b, -c, --cache, -m 350 6

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 7

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 8

Example Low System (e. g. public info) LS High System (e. g. private info) NRL PUMP Statistically modulated ACK Buffer Data HS 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. LS Ready to send Got ACK Send Data Waiting ACK NRL Pump (Probabilistic) Properties: Minimize information flow from HS to LS. Enforce reasonable performances, i. e. : = HS Ready to receive Read Data Send ACK Done 9

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 2 GHz Intel Pentium PC with Linux OS and 512 MB of RAM). 10

Covert Channel Exp: Pdec, Pwrong as a function of the number of steps h 11

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 1 ms). 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. 12

Reliability Analysis: 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 13

A Control System Disturbances: electric users, param. var, etc Settings Fuel Valve Opening FG 102 Gas Turbine (Turbogas) Controller Vrot, Texh, Pel, Pmc Vrot: Turbine Rotation speed Texh: Exhaust smokes Temperature Pel: Generated Electric Power Pmc: Compressor Pressure 14

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| /M 2 p(v, i) = 0. 2 0. 4 + b*(M - v)*|M - v| /M 2 -0. 4 <= b <= 0. 4 when i = 1 when i = 0 when i = -1 The further u(t) from u 0 (nominal user demand) the higher u(t) probability to return towards u 0. That is to decrease when u(t) > u 0, to increase when u(t) < u 0. 15

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. 373292 e-05 3500 2, 226, 036 6, 602, 763 1400 50263 1. 076644 e-04 4500 1, 834, 684 5, 439, 327 1300 41403 9. 957147 e-05 5000 83, 189 246, 285 900 2212 3. 984375 e-03 16

Mutual Exclusion (Mutex) n 2 t 2 c 2 T= 2 1 2 T 1& S 1 = T= 1 2& S 1=n 1 & S 2=t 2 S 1 =t c 1 S 2 =t S 2 = S 2 n 1 t 1 n 2 n 1 S 2=n 2 & S 1=t 1 n 1, n 2, 1 t 1, n 2, 1 c 1, n 2, 1 n 1, t 2, 1 t 1, t 2, 1 c 1, t 2, 1 n 1, c 2, 1 t 1, c 2, 1 c 1, c 2, 1 n 1, n 2, 2 t 1, n 2, 2 c 1, n 2, 2 n 1, t 2, 2 t 1, t 2, 2 c 1, t 2, 2 n 1, c 2, 2 t 1, c 2, 2 c 1, c 2, 2 SPEC Mutual exclusion: No starvation S 1: AG (S 1 != c 1 | S 2 != c 2) … true AG (S 1 = t 1 --> AF (S 1 = c 1)) … true 17

Mutex (~ arbitrary initial state) 2 1 T 2 1& S 1 = T= 1 T= 2& Mutual exclusion: No starvation S 1: c 2 S 1=n 1 & S 2=t 2 S 1 =t c 1 S 2 =t S 2 = n 2 S 2 n 1 t 1 n 2 n 1 S 2=n 2 & S 1=t 1 AG (S 1 != c 1 | S 2 != c 2) … AG (S 1 = t 1 --> AF (S 1 = c 1)) … 18

SMV output (mutex) -- specification AG (S 1 != c 1 | S 2 != c 2) is true -- specification AG (S 1 = t 1 -> AF S 1 = c 1) 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 19

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 20

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. 21

TOOLS http: //www. dsi. uniroma 1. it/~tronci/cached. murphi. html Caching Murphi (Cmurphi) (also http: //www. stanford. edu/) Cmurphi (Rome “La Sapienza”, L’Aquila) 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 allows Finite Horizon Analysis of Markov Chains modelling stochastic hybrids systems. Unlike PRISM, FHP-Murphi can handle real numbers. 22

Automatic Verification: A Money Saver Errors caught (percent) 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 Number of times more expensive to fix Early development Implementation 23

Open Source Model Checkers Here a few examples of open source model checkers. SMV, Nu. SMV (Carnegie Mellon University, IRST) [smv, VHDL / CTL] SPIN (Bell Labs) [PROMELA (C like)/ LTL] Murphi (Stanford, Roma “La Sapienza”, L’Aquila) [Pascal like/assert() style] VIS (Berkeley, Stanford, Colorado University) [BLIF, Verilog/CTL, LTL] PVS (Stanford) [PVS/PVS] TVLA (Tel-Aviv) [TVLA/TVLA] Java Path. Finder (NASA) [Java Bytecode/LTL] BLAST (Berkeley) [C/assert()] 24

Java Verification (BANDERA) SAn. To. S Group at Kansas State University 25

Some Commercial Model Checkers Here a few examples of commercial model checkers. Cadence (Verilog, VHDL) Synopsis (Verilog, VHDL) Innologic (Verilog) Telelogic (inside SDL suite) Esterel Coverity (C, C++) 26

In House Model Checkers Here 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] 27

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. 28