Automated revision of existing programs
Download
1 / 38

Automated Revision of Existing Programs - PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on

Automated Revision of Existing Programs. Software Engineering and Network Systems Laboratory (SENS). Borzoo Bonakdarpour. Motivation. Question : Is it possible to revise the model automatically such that it satisfies the failed property while preserving the other properties?. Model

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Automated Revision of Existing Programs' - yoshino-gen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Automated revision of existing programs

Automated Revision of Existing Programs

Software Engineering and Network Systems Laboratory (SENS)

Borzoo Bonakdarpour


Motivation
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


Motivation cont d

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


Outline
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


Program revision

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


Our goal
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


Part I:

Adding Properties to Existing Programs

Automated Revision of Existing Programs


Preliminary concepts
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


Preliminary concepts cont
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


Preliminary concepts cont1
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


Problem statement
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


Adding a single leads to property r t
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


Adding a single leads to property r t1
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


Soundness and completeness
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


Adding two leads to properties
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


Other results
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


Another problem

Q

T

Another Problem

Adding two eventually properties

  • trueleads-toQ:

  • trueleads-toT:

    This problem is also NP-complete!

Automated Revision of Existing Programs


Example real time resource allocation

{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



Example cont d

{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


Part II:

Adding Fault-Tolerance to Existing Programs

Automated Revision of Existing Programs


The byzantine agreement problem

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


The byzantine agreement problem1

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


The byzantine agreement problem2
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


The byzantine agreement problem3
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


Some terminalogy
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


Preliminaries cont d
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


Levels of fault tolerance 3
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


Fault tolerant real time programs
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


New levels of fault tolerance for rt programs
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


Levels of fault tolerance cont d
Levels of Fault-Tolerance (cont’d)

Automated Revision of Existing Programs


Problem statement1
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


Problem statement2
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


Current results
Current Results

[2] S. Kulkarni, A. Arora, Automating the Addition of Fault-Tolerance, FTRTFT 2000

Automated Revision of Existing Programs


Example altitude switch
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


Ongoing research
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


Conclusion
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


Questions?

Automated Revision of Existing Programs


ad