automated revision of existing programs
Download
Skip this Video
Download Presentation
Automated Revision of Existing Programs

Loading in 2 Seconds...

play fullscreen
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 PropertyMotivation (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

slide7
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

slide21
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

slide38
Questions?

Automated Revision of Existing Programs

ad