Automated Revision of Existing Programs

1. Automated Revision of Existing Programs Software Engineering and Network Systems Laboratory (SENS) Borzoo Bonakdarpour

2. Motivation Question : Is it possible to revise the model automatically such that it satisfies the failed property while preserving the other properties? Model Checker Model Property Counterexample Automated Revision of Existing Programs

3. New Property Motivation (cont’d) Question: Is it possible to add a newly discovered property to an existing program automatically? Incomplete Specification Requirements Specification Designer Program Automated Revision of Existing Programs

4. Outline • What is program revision? • Adding properties to existing programs • Results • Example • Adding fault-tolerance to existing real-time programs • Results • Example • Ongoing research, Open problems, and Future work Automated Revision of Existing Programs

5. P   ╨ Program Revision ProgramP Revision Algorithm • Revision by synthesis • From specification: Comprehensive revision • Highly expensive • No reusability • From the existing program + new property: Local revision • Provides reusability • In some cases, offers lower classes of time and space complexity • Does not need to have the entire specification of the existing program Property  Automated Revision of Existing Programs

6. Our Goal Question: Why comprehensive revision is highly complex? Answer: Expressiveness of specifications • We identify classes of interesting properties typically used in specifying reactive systems. • Designing synthesis methods where revising existing programs is feasible time-wise and space-wise. Automated Revision of Existing Programs

7. Part I: Adding Properties to Existing Programs Automated Revision of Existing Programs

8. Preliminary Concepts • A programpis a triple p = Sp , Ip , p, i.e., finite state space, set of initial states, and program transitions. • A state predicateis any subset of Sp. • A computationis a state sequence s0 , s1 , … iff • s0  Ip • i > 0 : (si-1 , si) p • If  terminates in state sf then there does not exist s such that (sf , s) p. Automated Revision of Existing Programs

9. Preliminary Concepts (cont.) • Sample Properties • Safety: • PunlessQ : • stable(P): • invariant(P): • Liveness: • P leads-toQ: P P P Q P P P P P P P P P P Q Automated Revision of Existing Programs

10. Preliminary Concepts (cont.) • A specification is a conjunction of a set of properties: spec = L1 L2 … Ln • A computationsatisfiesspec iff (i | 0  i  n :  satisfies Li) • A programpsatisfiesspec iff all computations of p • are infinite • satisfy spec. Automated Revision of Existing Programs

11. Problem Statement Program p = Sp, Ip, p Synthesis Algorithm • Formulation of the problem: • p satisfies existing specification spece • Sp = Sp • Ip = Ip • p  p • All computations of p • are infinite • satisfy specn. Program p = Sp, Ip, p A Specification specn Automated Revision of Existing Programs

12. Adding a Single Leads-to Property (R T ) Case 1 : Deadlock states Remove transitions (s1, s2) if s2 R and T is not reachable from S2 Sp s1 Ip s0 R T s2 Automated Revision of Existing Programs

13. Adding a Single Leads-to Property (R T ) Case 2: Cycles Break cycles reachable from R without reaching Q. Sp Ip R T s0 s4 s1 s2 s3 Automated Revision of Existing Programs

14. Soundness and Completeness • Theorem (1) The algorithm for adding multiple safety properties along with a leads-to property is sound and complete. • Fixability • Theorem (2) The complexity of the algorithm for adding multiple safety properties along with a leads-to property is polynomial-time. Automated Revision of Existing Programs

15. Adding Two Leads-to Properties • Adding two leads-to properties one after another Sp T Ip R s6 s0 s2 s3 s1 s4 s5 s7 s6 s8 s9 Q P Automated Revision of Existing Programs

16. Other Results • The problems of simultaneous addition of two leads-to properties is NP-complete. • The problem of adding one leads-to property while maintaining maximum non-determinism is NP-complete. Automated Revision of Existing Programs

17. Q T Another Problem Adding two eventually properties • trueleads-toQ: • trueleads-toT: This problem is also NP-complete! Automated Revision of Existing Programs

18. {x} {x} Example: Real-Time Resource Allocation • Two processes j  {1, 2}. • Each has two tasks to complete (each takes 1 time unit) • Submitting a request • Performing I/O operation RQj : req.j (x = 1) io.j, req.j := true, false ; IOj : io.j (x = 1) req.j, io.j := true, false ; WT : 0 x 1 􀀀 wait; Bounded response: L  (io.1  2req.1) Automated Revision of Existing Programs

19. Automated Revision of Existing Programs

20. {x, t} {x} {x} {x} Example (cont’d) RQ1 : req.1  (x = 1) io.1, req.1 := true, false ; IO1 : io.1  (x = 1) req.1, io.1 := true, false ; RQ2 : req.2  (x = 1)  (io.1 t 1) io.2, req.2 := true, false ; IO1 : io.2  (x = 1)  (io.1 t 1) req.2, io.2 := true, false ; WT : 0 x 1 􀀀 wait; Automated Revision of Existing Programs

21. Part II: Adding Fault-Tolerance to Existing Programs Automated Revision of Existing Programs

22. Decision Final? d.j d.k  {0, 1, } d.l f.j f.k  {false, true} f.l The Byzantine Agreement Problem GENERAL Decisiond.g {0, 1} NON-GENERALS (d.j = )  ( f.j = false) d.j := d.g (d.j)  ( f.j = false) f.j := true Program: Automated Revision of Existing Programs

23. Byzantine? b.j b.k  {false, true} b.l The Byzantine Agreement Problem Byzantine? b.g {false, true} (b.j ,b.k , b.l , b.g = false) b.j := true (b.j := true) d.j := 0|1 Faults: Automated Revision of Existing Programs

24. The Byzantine Agreement Problem • Safety specification • Agreement:The final decision of any two non-Byzantine process cannot be different. • Validity:If the general is non-Byzantine then the final decision of a non-Byzantine process must be the same as that of the general. • Fact : The program does not meet the safety specification in the presence of faults: • d.g = 0, b.g = true • d.j = 0, f.j = false  f.j := true • d.k = 1, f.k = true Automated Revision of Existing Programs

25. The Byzantine Agreement Problem • Question Is it possible to revise a distributed program in order to add fault-tolerance to the original program with respect to a safety specification and a class of faults? • Answer Yes, but the problem is NP-complete, which itself is a problem! • Solution A set of polynomial-time heuristics has been developed to add fault-tolerance to a large class of distributed programs. Automated Revision of Existing Programs

26. Some Terminalogy • Boolean Variables:V = {v1 vn} • State:where l(vj) is a literal. • State predicate:A finite set of states • Transition:Let V  = {v | v V}. A transition (s, s) = ss. • Transition predicate:is a set of transitions • Program:A program is defined by a transition predicate P. • Closure:A state predicate S is closed in program P iff (s ||S)  (s ||S) • Computation of P:A sequence of states s0, s1 where (sj, sj+1) || P • Safety specification:A set of bad transitionsthat should not occur in any program computation, defined by transition predicate SPEC. • Satisfaction:A program P satisfies SPEC from S iff • S is closed in P • For all s0, s1 where s0 || S, (sj, sj+1) || SPEC • Invariant:If P satisfies SPEC from S and S {} then S is an invariant of P. Automated Revision of Existing Programs

27. Preliminaries (cont’d) • Faults:A set F of transitions. • Fault-span:A state predicate T such that • S T • T is closed in P  F. f Fault-Span p p Invariant f f f p p f Finite state space • Fault-tolerance:A program P is F-tolerant to SPEC from S if: • P satisfies SPEC from S • There exists T such that: • T is an F-span of P • P F satisfies SPEC from T (safety) • after faults stop occurring, every computation of P reaches S (liveness). Automated Revision of Existing Programs

28. Levels of Fault-Tolerance [3] • In the presence of faults: • Afailsafe program satisfies the safety specification • Anonmasking program satisfies the liveness specification • Amasking program satisfies both safety and liveness specifications • In the absence of faults the program must continue to satisfy its entire specification Question: Are these levels able to capture the requirements for modeling fault-tolerant real-time programs? [3] A. Arora, S. Kulkarni, Designing masking fault-tolerance via nonmasking fault-tolerance, TSE 1998 Automated Revision of Existing Programs

29. Fault-Tolerant Real-Time Programs • Railroad Crossing • Safety: If the train is passing the crossing, the gate must be closed. • Bounded response : Once the gate is closed, it should reopen within 4min. • Fault-tolerance : The gate must be closed while the train is passing the intersection even in the presence of faults. • Boiler Controller • Bounded response:Once the pressure gauge reads 30 pounds per square inch, the controller must issue a command to open a valve within 20s. • Fault-tolerance : Faults should not affect the functionality of the controller. Automated Revision of Existing Programs

30. New Levels of Fault-Tolerance for RT Programs • Soft Fault-Tolerance A program is soft fault-tolerant if it is NOT required to satisfy its timing constraints in the presence of faults. However, it should continue to meet its timing constraints in the absence of faults. • Hard Fault-Tolerance A program is hard fault-tolerant if it is required to satisfy its timing constraints evenin the presence of faults . Automated Revision of Existing Programs

31. Levels of Fault-Tolerance (cont’d) Automated Revision of Existing Programs

32. Problem Statement ProgramP Synthesis Algorithm Fault-tolerant programP Safety spec.  Set of faults f { Soft/Hard-Failsafe Nonmasking Soft/Hard-Masking Desired level of fault-tolerance: Automated Revision of Existing Programs

33. Problem Statement • Given program P, Invariant S, a set of faults F, and safety specification SPEC, identify a program P with invariant S such that: • SS, • PP, and • P is F-tolerant to SPEC from S. Automated Revision of Existing Programs

34. Current Results [2] S. Kulkarni, A. Arora, Automating the Addition of Fault-Tolerance, FTRTFT 2000 Automated Revision of Existing Programs

35. Example: Altitude Switch The Altitude Switch is required to: 1) HFS: Tolerate the delay fault while in Standby mode  ((Standby  CorruptSensor) ◊2(Init)) 2) HFS: Not power on the actuators while it fails to read the altitude sensors. 3) SMK: Recover within 1s after occurrence of faults << Reset >> (CorruptSensor  y  2)? << SensorFail>> [y := 0] [x, y, z := 0] Standby (x 0.6)? Init x 0.6 y 1 y 2 << LowAlt>> [z := 0] << Reset >> ( Power)?  (Power  CorruptSensor)? (x > 0.6)? [t := 0] (t 1)? (y > 2)? [t := 0] Await (z > 2 )? [t := 0] (Power z  2 )? >> ActuatorPower on << z 2 Fault-span (Power z  2 )? Automated Revision of Existing Programs

36. Ongoing Research • Implementation of the algorithms • Coping with the state explosion problem: • Synthesis using zone automata • Parallelizing state space • Coping with NP-hardness results: • Heuristics • Decision procedures (Yices) • Fault-tolerance in hybrid systems [8] http://www.cse.msu.edu/.ebnenasi/research/tools/ftsyn.htm. Automated Revision of Existing Programs

37. Conclusion • We study the problem of automated revision of programs inside their state space: • Adding properties to programs • Adding fault-tolerance Automated Revision of Existing Programs

38. Questions? Automated Revision of Existing Programs