Applications of control to formal software semantics Eric

Applications of control to formal software semantics Eric Feron Aerospace Engineering Georgia Tech (with Fernando Alegre, Alwyn Goodloe, Romain Jobredeaux, Tim Wang + a growing number of guests of Alwyn’s at NIA) July 15, 2010 NSV 3

Take-Home Message We’ve got proofs for our control systems, so let’s use them beyond cool research papers, inside software (Probable NSV interpretation: Yet another guy who’s discovered static analyzers and formal proofs)

Outline • • • A simple control example Stability and performance analyses Why code-level analyses? Hoare logic and partial correctness Analysis of controller implementation Closed-loop system analysis

A simple control example · d dt x x _ ¸ · = y = ¸· 0 1 x ¡ 1 0 x _ · ¸ x : [1 0] _ x ¸ · + 0 1 ¸ u; x(0) = x 0 _ _

A simple control example (Ct’d) ~ y(t) = SA T (y(t)); s + 1 s=5 + 1 = 128 u(s) y(s); ~ s + 0: 1 s=50 + 1 Step response

Controller implementation y(t) = SA T (y(t)); ~ s + 1 s=5 + 1 = 128 y(s); u(s) ~ s + 0: 1 s=50 + 1 · xc = ¡ 50: 1 ¡ 5: 0 1: 0 0: 0 = u d dt = uk = · xc + 100 0 ¸ SA T (y) State-space realization ¡ [564: 48 0] x c + 1280 SA T (y): · x c; k + 1 ¸ 0: 499 ¡ 0: 050 0: 010 1: 000 ¸ · x c; k + 1 0 ¸ SA T (yk ) ¡ [564: 48 0] x c; k + 1280 SA T (yk ) Discrete time Implementation 100 Hz

Controller Program A = [ 0. 4990, - 0. 0500; 0. 0100, 1. 0000] ; 2: C = [ - 564. 48, 0] ; 3: B = [ 1; 0] ; D = 1280; 4: x = zer os( 2, 1) ; 5: whi l e 1 6: f y = f scanf ( st di n, " % " ) ; 7: ax( i y = m m n( y, 1) , - 1) ; 8: u = C* x + D y; * 9: f pr i nt f ( st dout , " % n" , u) ; f 10: x = A* x + B* y; 11: end 1: MATLAB

Controller Program 1: i nt m n( i nt ar gc, char *ar gv[ ] ) ai 2: { 3: doubl e *x[ 2] , *xb[ 2] , y, u; 4: x[ 0] = 0; 5: x[ 1] = 0; 6: hi w l e( 1) { y) 7: f scanf ( st di n, "%", & ; f 8: i f ( y >1) { y=1 9: } 10: 11: i f ( y<- 1) { y=- 1 12: } 13: 14: u = - 564. 48*x[ 0] +1280* y; 15: f pr i nt f ( st dout , "% n", u) ; f 16: xb[ 0] =x[ 0] ; xb[ 1] =x[ 1] ; 17: x[ 0] : = 0. 4990*xb[ 0] - 0. 0500*xb[ 1] +y; 18: x[ 1] : = 0. 01*xb[ 0] +xb[ 1] ; 19: 20: } 21: } C

Control system as seen by control engineers System data System Identification/ model Validation Controller design Validated Controller Invalidated Controller Not good to go Good to go Control system analysis ! M LE B O Implementation R P Y M T O Verification and Validation N Manual coding Executable Compiler Source code Matlab/ Simulink/ Real-time Workshop Matrix. X Picture 2 code (UTC)

Code-level analyses of control software • • Significant contribution from Patrick Cousot’s group at Ecole Normale Superieure, Paris and NYU. Abstract interpretation supports capturing semantics of programs Most important application is ASTREE analyzer for Airbus A 380 control code. From Feret, “Static Analysis of Digital Filters”, 2004 (also with ASTREE).

Making sense out of computer programs • Consists of asking: “Where can the program go? Does it do what it’s supposed to do? ” • Well-known limits to what can be done. • Several options are available: “Formal Methods” – Model checking – Abstract interpretation

Desirable attributes of “program proofs” • Must be expressive enough to tell nontrivial statements about program • Must be “elementary enough” so that each “proof element” can be verified using only local program elements. “Line-by-line verification”.

Hoare logic: While programs • • • Assignments y: =t Composition S 1; S 2 If-then-else if e then S 1 else S 2 fi While e do S od Hoare logic consist of instrumenting each line with “what it does to the state-space” assi gnm ent ) f st at e-space st at ement 1 g à pr econdi ti on assi gnm ent f st at e-space st at ement 2 g à postcondi ti on Compositionality: f pr e 1 gl oc 1 f post 1 g; f pr e 2 gl oc 2 f post 2 g ^ (f post 1 g ! f pr e 2 g) ) f pr e 1 gl oc 1; l oc 2 f post 2 g See Peled, 2001, Monin, 2000

Example: Capturing controller behavior The control-systemic way · x c; k + 1 = uk = 0: 499 ¡ 0: 050 0: 010 1: 000 ¸ · 1 0 x c; k + ¸ SA T (yk ) ¡ [564: 48 0] x c; k + 1280 SA T (yk ) Assume t he cont roller st at e is init ialized at x c; 0 = 0 What range of values could be reached by t he st at e x c; k and t he cont rol variable uk ? There is a variety of options, including computation of -1 norms. A Lyapunov-like proof (from Boyd et al. , Poola): · The ellipsoid © ª 2 j x. T P x · 1 : EP = x 2 R P = 10¡ 3 0: 6742 0: 0428 2: 4651 ¸ is invariant. None of the entries of x exceeds 40 in size. How do you say the same thing about the program that implements the controller?

A Matlab program A = [ 0. 4990, - 0. 0500; 0. 0100, 1. 0000] ; 2: C = [ - 564. 48, 0] ; 3: B = [ 1; 0] ; D = 1280; 4: x = zer os( 2, 1) ; 5: whi l e 1 6: f y = f scanf ( st di n, " % " ) ; 7: ax( i y = m m n( y, 1) , - 1) ; 8: u = C* x + D y; * 9: f pr i nt f ( st dout , " % n" , u) ; f 10: x = A* x + B* y; 11: end 1: f tr ueg 4: x = zer os( 2, 1) f x 2 EP g g. 5: w l e 1 hi f x 2 EP g 6: y = f scanf ( st di n, " % " ) f f x 2 EP g = m m n( y, 1) , - 1) ; 7: ax( i ª © y x 2 EP ; y 2 · 1 = C x+D y; 8: * * © u ª x 2 EP ; u 2 · 2(CP ¡ 1 C T + D 2 ); y 2 · 1 9: f pr i nt f ( st dout , " % nn" , u) f f x 2 EP ; y 2 · 1 g. © A x + B y 2 EP ; y 2 · 1; ª u 2 · 2(CP ¡ 1 C T + D 2 ) 9: © f pr i nt f ( st dout , " % nn" , u) ªf A x + B y 2 EP ; y 2 · 1. 10: x = A* x + B* y; f x 2 EP g 11: end f f al seg < ?

Critical step is true for the particular instances of A, B, P. (ellipsoid invariance condition)/ -Either leave it as is to check via automated checker that can handle systems of polynomial inequalities (eg Zumkeller, Thery 2008) -Or provide additional proof element: 8(x; y) (Ax + B y) T P (Ax + B y) ¡ 0: 01 x T P x ¡ 0: 99 y 2 · 0: 0 g f x 2 EP ; y 2 · 1; (Ax + B y) T P (Ax + B y) ¡© 0: 01 x T P x ¡ 0: 99 y 2 · ª ) Ax + B y 2 EP ; y 2 · 1 ;

f t rueg 1: A = [ 0. 4990, - 0. 0500; 0. 0100, 1. 0000] ; Commented f t rueg 2: C = [ - 564. 48, 0] ; f t rueg 3: B = [ 1; 0] ; D=1280 f t rueg 4: x = zer os( 2, 1) ; f x 2 EP g 5: whi l e 1 f x 2 EP g 6: y = f scanf ( st di n, " % " ) f f x 2 EP g ax( i n( 7: y = m m ª y, 1) , - 1) ; © x 2 EP ; y 2 · 1 * * 8: u = C x+D y; f x 2 EP ; u 2 · 2(CP ¡ 1 C T + D 2 ); y 2 · 1 g 9: f pr i nt f ( st dout , " % nn" , u) f f x 2 EP ; y 2 · 1; (A x + B y) T P (Ax + B y) ¡ 0: 01 x T P x ¡ 0: 99 y 2 · 0 g ski © p ª 2 · 1 A x + B y 2 EP ; y 10: x = A* x + B* y; f x 2 EP g 11: end code

Forward constraint propagation A = [ 0. 4990, - 0. 0500; 0. 0100, 1. 0000] ; 2: C = [ - 564. 48, 0] ; 3: B = [ 1; 0] ; D = 1280; 4: x = zer os( 2, 1) ; 5: whi l e 1 6: f y = f scanf ( st di n, " % " ) ; 7: ax( i y = m m n( y, 1) , - 1) ; 8: u = C* x + D y; * 9: f pr i nt f ( st dout , " % n" , u) ; f 10: x = A* x + B* y; 11: end 1: · Q= 0: 01 P 0 0 0: 99 ¸ f tr ueg 1: A = [ 0. 4990, - 0. 0500; 0. 0100, 1. 0000] ; f tr ueg 2: C = [ - 564. 48, 0] ; f tr ueg 3: B = [ 1; 0] ; D = 1280; f tr ueg 4: x = zer os( 2, 1) ; f x 2 EP g 5: whi l e 1 f x 2 EP g 6: y = f scanf ( st di n, " % " ) ; f f x 2 EP g ax( i 7: y = m m n( y, 1) , - 1) ; f x 2 EP ; y 2 · 1 g f ( x y ) 2 EQ g * 8: u = C x + D* y; f ( x y ) 2 EQ ; u 2 · [C D ] Q¡ 1 [C D ]T g 9: f pr i nt f ( st dout , " % nn" , u) ; f f ( x y ) 2 EQ g 10: x = A* x + B* y; f x 2 E( 1 A P ¡ 1 A T + 1 B B T ) ¡ 1 g 0: 01 f x 2 EP g 11: end f f alseg < 0: 99

2 C code analysis ai 1: i nt m n( i nt ar gc, char * ar gv[ ] ) 2: { 3: doubl e * x[ 2] , * xb[ 2] , y, u; 4: x[ 0] = 0; 5: x[ 1] = 0; 6: whi l e( 1) { 7: f scanf ( st di n, " % " , &y) ; f 8: i f ( y >1) { y=1 9: 10: } 11: i f ( y<- 1) { y=- 1 12: 13: } u = - 564. 48* x[ 0] +1280* y; 14: 15: f pr i nt f ( st dout , " % n" , u) ; f xb[ 0] =x[ 0] ; 16: xb[ 1] =x[ 1] ; 17: x[ 0] : = 0. 4990* xb[ 0] - 0. 0500* xb[ 1] +y; 18: 19: x[ 1] : = 0. 01* xb[ 0] +xb[ 1] ; 20: } 21: } 3 2 1 x[1] f x 2 EP 7 g 6 6 x[2] = 4 0 4 8: y i f 5( y >1) 0 f f x 2 EP ; y > 1 g xb[1] 1 9: y=1 E f x 2 ©P ; y · 1 g = xj ER ¡ 10: ½ g · x T R ¡ 1 x. T f=x 2 x. Ej. P ; y 1· 1 g GR x R ½· x y ¸ ª = · 1 ¾ ¸ ¸ 0 · ¾ 2 EQ 3 # 0 " x[1] 0 7 5 x[2] 1 y 0 0 1 0 0 Q= 16: xb[ 0]3=x[ 0] 9 82 x < = 4 y 5 2 G R; : xb[1] 2 3 1 0 0 6 7 = 6 0 1 0 7 Q¡ R 4 0 0 1 5 1 0 0 0: 01 P 0 2 1 6 0 16 4 0 1 0 0: 99 0 1 0 0 ¸ 3 0 T 0 7 7 1 5 0

Applications (auto) Code analyzer Controller Specifications (+proof) Autocoder (auto)-code (third party) Code analyzer Proof Go/no Go (certification Authority) (user) Credible autocoder (a la Rinard) Controller Specifications +proof Credible autocoder (third party) (user) Documented (auto)-code Proof checker (certification Authority) Go/no-go

Other important questions • Verifying closed-loop system • So far made assumption that analyzer could handle real numbers like you and me…. • Many controllers are more complex than a simple lead-lag controller – nonlinear? Adaptive? Receding horizon? ? ?

More Complex Control Systems Adaptive systems a, b unknown Reference model Adaptive control architecture Nonquadratic invariant structure!

Closed-loop system representations Plant Controller

Concurrent Representations of System and Controller %Controller dynamics

Actual Computations • Computations do not follow real arithmetic – Fixed/Floating-point computations are often neglected during specification phase, comes back as “thorn in foot” during implementation. – Neglect at specification level makes typical “leaky abstraction” – Justified because detailed computations are typically left aside when spec-ing system • Computation model that’s agreeable/manageable by everybody

Additive/multiplicative uncertainty model (Discussions with Eric Goubault & Sylvie Putot) x real x ° oat = x(1 + ¢ 1(x)) + ¢ 2(x) IEEE 754: x, y floats (x + y) ° oat = (x + y)(1 + ¢ 1(x + y)) + ¢ 2(x + y) Same for ¡ , £ , = Only upper bounds are known on ¢ 1(: ); ¢ 2(: ) eg j¢ 1(: )j · M 1; j¢ 2(: )j · M 2

Consequence on invariance conditions Ellipsoidal invariance condit ion becomes © ª x 2 EP ; y 2 · 1 © ª ) F (x; y; ¢ 1; ¢ 2; : : : ; ¢ M ) 2 EP ; y 2 · 1 Back to proof checker / proof assistant that can handle systems of polynomial inequalities (eg Zumkeller, Thery 2008)

Conclusion • Stability and performance proofs of control systems fundamentally compatible with formal static analysis and verification methods – must feed available information in “system assembly process”. • Must write software development tools that run across layers of implementation and are compatible with verification preferences/levels of rigor favored by different communities.