Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul...

Pervasive Self-Regeneration through Concurrent

Model-Based Execution

Brian Williams (PI)Paul Robertson

MITComputer Science and Artificial Intelligence Laboratory

1/27/05 SRS PI Meeting 2

OverviewTechnical Objective:

When software fails, because of (a) environment changes (b) software incompatibility (c) hostile attack, (1) recognize that a failure has occurred, (2) diagnose what has failed and why, and (3) find an alternative way of achieving the intended behavior.

Technical approach:Achieve robustness to software failures by combining

RMPL’s capability for managing hardware redundancy with methods for managing functional redundancy. Involves:

(1) Detection (2) Diagnosis (3) Reconfiguration(4) Model-predictive Dispatch

RMPL Models of:Software Components,

Component Interconnectivity,and correct behavior.


Expected AchievementsEnable:• Software systems that can operate autonomously to

achieve goals in a complex and changing environment.– Modeling environment

• Software that detects and works around “bugs” resulting from incompatible software changes.– Modeling software components

• Software that automatically improves as better software components and models are added.

• Software that detects and recovers from software attacks.– Modeling attack scenarios

• Testbed: High level command and control of robotic missions.


Task Schedule

.

ID

Task Name 2004 2005

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

1 Testbed instrumentation for observation and control

2 Languages and development tools

3 Communicating model-based executives

4 Method deprecation

5 Method regeneration

6 Decision theoretic method dispatch

7 Testbed integration and modeling


Outline

• Overview

• Recap

• Language Design– Representing component behavior– Representing redundant timed methods

• Implementing model-predictive dispatch


Model-Based Executive Architecture

SPlant

Obs Cntrl

Model-basedEmbedded Programs

S

ContinuousReactive

Commanding

Continuous Mode/StateEstimation

Model

Desiderata: languages that are:Suspicious

Monitor intentions and procedures

Self-AdaptiveExploits and generates contingencies

State and Fault AwareAnticipatory

“Model-predictive languages”Plans and verifies into the futurePredicts future states

Plans contingencies


Rover test bed

Allows real-world testing of robustness throughmodel-based execution

Consists of a reconfigurable environment with one ATRV-2 and three ATRV-JRs.


Language Design

• Basic Constructs

• Expressing component behavior– Stochastic behavior

• Expressing timed, redundant methods– Multiple methods– Temporal relations– Exceptions


RMPL to PHCA encoding

A

always { A }

A c

if (c) { A }

A c

unless (c) { A }

B

parallel { A; B }

A

c

c


Example RMPL component// exports domain {Off, On, Failed}class Camera { private Power power_in; // sensor, not exported private Shutter shutter; // sensor, not exported

Camera (Power power_in_sensor, Shutter shuttor_sensor) {power_in = power_in_sensor;shutter = shuttor_sensor;

}

initial value Off =((power_in == None) & (shutter == Closed)){ primitive method cameraOn () => On [reliability: .99];}

value On =((power_in == Nominal) & (shutter == Open)){ method cameraOff () => Off [reliability: .99];}

failure value Failed = True // unconstrained{ primitive method reset () => Off [reliability: .99]; }

// from any mode of Camera primitive method fail () True => Failed [reliability: .01]; transition fail True => Failed [probability: .001]; transition fail Off & (power_in == Low) => Failed [probability: .01];}


Probabilistic Transitions

A

B

C

p

q

r

choose with probability: p { A } with probability: q { B } with probability: r {C }


RendezvousRendezvous Rescue AreaRescue Area

Corridor 2

Corridor 1

Enroute

RMPL Example: Redundant Timed Methods


RMPL for Group-Enroutemethod GroupEnroute()[l,u] { sequence { choose { do { [l*90%,u*90%] GroupTraversePath(PATH1_1,PATH1_2,PATH1_3,RE_POS); } maintaining PATH1_OK; do { [l*90%,u*90%] GroupTraversePath(PATH2_1,PATH2_2,PATH2_3,RE_POS); } maintaining PATH2_OK }; parallel { [0,2] GroupTransmit(OPS,ARRIVED); do { [0,u*10%] GroupWait(HOLD1,HOLD2) } watching PROCEED } }}



Activities:



Sequentiality:Concurrency:



Conditionalityand Preemption:



Temporal Constraints:


RMPL for Group-Enroutemethod GroupEnroute()[l,u] { sequence { choose { do { [l*90%,u*90%] GroupTraversePath(PATH1_1,PATH1_2,PATH1_3,RE_POS); } maintaining PATH1_OK; do { [l*90%,u*90%] GroupTraversePath(PATH2_1,PATH2_2,PATH2_3,RE_POS); } maintaining PATH2_OK }; [0,2] GroupTransmit(OPS,ARRIVED); do { [0,u*10%] GroupWait(HOLD1,HOLD2) } watching PROCEED } }}

Non-deterministicchoice:


Temporal Relations Between Concurrent Sub-Processes

• Add ability to relate arbitrary RMPL sub-processes

endof(A) > startof(B)

startof(A) < startof(B), endof(A) > endof(B)

endof(A) = startof(B)

endof(A) > endof(B)

endof(A) < startof(B)

startof(A) < startof(B)

startof(A) = startof(B), endof(A) = endof(B)

AB

AB

A B

AB

A B

AB

AB


Scoped Labeling of Sub-Processes Added RMPL constructs:

– <label>: <sub-process>• Gives a label to an RMPL sub-process• Eg: ‘x’: [l,u] A

– constrained <sub-process> temporal constraints

• Scoping: Constraints only refer to labels within sub-process.

– temporal constraints:<label> <inequality> <label>

• Temporally relates two sub-processes

[l,u] A

Label ‘x’


Example: Temporal Constraint

constrained parallel {

sequence { A; b: B };

sequence { C; d: D } }

startof(b) ≤ startof(d)

A B

C D

[0,+INF]

Label ‘b’

Label ‘d’


Example: Metric Constraint

• Example: constrained

parallel { sequence {

A; b: B };

sequence { c: C; D } }

endof(c) - startof(b) in [10,20]

A B

C D

[10,20]

Label ‘b’

Label ‘c’


Exceptions

try { A }

catch e1 { B }

catch e2 { C }

catch e3 { D }

throw exceptionname

B

C

D

Ae1

e2

e3


Incorporating Model-Predictive Method Selection

1. Dynamically selects consistent methods over future horizon, 2. Adapts to uncertainty by selecting execution times dynamically, 3. monitors outcomes and plans contingencies.

Reactive Temporal Planner

Plan Runner

(Hidden) States

RMPL Program

CommandsObservables

Mode Estimation

Reactive Commanding

Model of Subsystems

• monitor activitiesmonitor activities• diagnose failuresdiagnose failures


Selecting Methods over a Horizon

RMPL Compiler

Temporal Plan Network (TPN)

Reactive Temporal Planner Selects schedulable execution threads of TPN

Reactive Model-based Programming Language

Concurrent Plan Plan = Execution

threads related by Simple Temporal Net

Represents all RMPL executions over horizon


Temporal Plan Network Example: Enroute Activity

1

4 5

8

9 10

13

2

11 12

Enroute

Group Traverse Group Wait

Group Transmit

Activity (or sub-activity)

Target

• Start with flexible plan representation


1

4 5

8

2Enroute [450,540]

[405, 486]


Group Transmit

[0, 54]

[0, 2]


Duration (temporal constraint)

[0, ]

[0, 0][0, 0]

[0, 0]

[0, 0]

[0, 0] [0, 0]

Target

• Start with flexible plan representation



3

1

4 5

8

2Enroute [450,540]

Group Traverse

[405, 486]

[405, 486]


Group Transmit

[0, 54]

[0, 2]



[0, ]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0] [0, 0]

Target

• Add conditional nodes

Conditional node



3

1

4 5

8

9 10

13

2

6 7 11 12

Enroute [450,540]

Group Traverse

[405, 486]

[405, 486]


Group Transmit

[0, 54]

[0, 2]



[0, ]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0]

[0, 0] [0, 0]

Ask( PATH1 = OK)

Ask( PATH2 = OK)

Ask( EXPLORE = OK)Target

•Add temporally extended, symbolic constraints

Symbolic constraint (Ask,Tell)

Conditional node



Planning Group-Enroute

3

6

4 5[405,486]

Ask(PATH1=OK)

1 2

7

Ask(PATH2=OK)

8

[405,486]

[450,540]

Ask(PROCEED)

11

9 10

[0,54]

12

13

[0,2]

[0,]

[0,] [0,]

14 15

Tell(PATH1=OK)

[450,450]16 17

Tell(PROCEED)

[200,200]

s e[500,800]

[10,10] [0,]

To Plan:• Instantiate Group-Enroute• Add External Constraints (Tells)

Group-Enroute

Group Traverse


Group Transmit

Target


Generates Schedulable Plan

3

6

4 5[405,486]

Ask(PATH1=OK)

1 2

7

Ask(PATH2=OK)

8

[405,486]

[450,540]

Ask(PROCEED)

11

9 10[0,54]

12

13

[0,2]

[0,]

14 15

Tell(PATH1=OK)

[450,450]16 17

Tell(PROCEED)

[200,200]

s e[500,800]

[10,10] [0,]

[0,] [0,]

Group-Enroute

Group Traverse


Group Transmit

Target

Trace consistent trajectories• Check Schedulability • Satisfy and Protect Asks

To Plan:• Instantiate Group-Enroute• Add External Constraints


Satisfying Asks• Find equivalent overlapping tell• Link ask to tell.• Constrain tell to contain ask.

5

7 8 9

10 11 12

6{4,6}

{4,6}

{4,6} {6,9}

{5,8} {7,11}

{7,10}

{8,11}

ask(c)

tell(c)


Avoiding Threats• Identify overlapping Inconsistent tells.

• Promote or demote.

5

7 8 9

10 11 12

6{4,6}

{4,6}

{4,6} {6,9}

{5,8} {7,11}

{7,10}

{8,11}

tell(c)

tell(c)

[0,infb]


Architecture Walkthrough

RMPLRMPL

CompilerTPN Macro

Library

1. The human writes a program in RMPL.

2. The RMPL program is compiled into Temporal Plan Network (TPN) fragments.



RMPLRMPL

CompilerTPN Macro

Library

Dispatch Kernel

Create Conditional CSP

Temporal Consistency Check

Tell Consistency Check

Ask Achievement Check

Location Consistency Check

Macro Expansion

Exception Handling Executiveplan updates

exceptions

TPN

TPN Graph Algorithms

Common DataRepository

Suite of Algorithms

FIFOSSSPSDSPAPSP

TPN updates

processedTPNdata

TPN data

TPN dataConditional CSPVariables

andDomains

Constraints

Conditional CSP Solver

CSP problem updates

partialsolutions


Tell(A=y)

Tell(A=x)

Initialize: Create CSP for TPN

Tell(B=x)

Tell(B=y)

Ask(B=x)

Start End

Step 1: Walk the TPN and create variables corresponding to the decision nodes

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

initialize


Start End

Step 2: Create variables and constraints corresponding to the non-causal link constraint arcs

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

initialize



Start End

We are left with a CSP that can be sent to the dynamic CSP solver

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

initialize




TPNDispatch Kernel






Macro Expansion

Exception Handling

TPN updates

TPN data

CSPVariables

andDomains

Constraints

Dynamic CSP Solver

CSP problem updates

partialsolutions

• The CSP passes the kernel a candidate plan for analysis

• The kernel executes a correct candidate

• When an activity fails, Exception Handling processes the exception and sets up replanning.

Executiveplan updates

exceptions


V8={ }

Tell(B=y)

Exception Handling

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

Tell(A=y)

Tell(A=x)

V7={ , }

V7

Tell(B=x)

Ask(B=x)

V8

Ask Consistency Check

1. Execution begins…2. An error occurs, and an exception is thrown

Partial Solution

V1={ }

V4={ }

V2={ }

V5={ }

V3={ }

V8={ }

EXCEPTION


Ask Consistency Check1. Execution begins…2. An error occurs, and an exception is thrown3. The exception-handling code is inserted

EXCEPTION

handlerdelay

The handler is the TPN sub-processcorresponding to the RMPL “catch” statement

that matches the thrown exception

The delay represents the amount of time spent in the original process before the

exception was thrown, plus an upper-bound on replanning time

Exception Handling


V8={ }

Tell(B=y)

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

V7={ , }

V7

Tell(B=x)

Ask(B=x)

V8


Partial Solution

V1={ }

V4={ }

V2={ }

V5={ }

V3={ }

V8={ }

EXCEPTION

1. Execution begins…2. An error occurs, and an exception is thrown3. The exception-handling code is inserted4. Replanning begins, pre-selecting anything

that has already been executed

Exception Handling


TPN Extensions:

Try-Catch Block

This new node design denotes the start of a

try-catch block


TPN Extensions:

Try-Catch Block

Nominal Trajectory

[l0,u0]

The nominal trajectory has a lower and

upper-timebound as usual


TPN Extensions:

Try-Catch Block

Nominal Trajectory

[l0,u0]

[0,u0] [l1,u1]Exception-A Trajectory Catch-A Trajectory

[0,u0] [l2,u2]

Exception-B Trajectory Catch-B Trajectory

Each exception trajectory can take from 0 to u0 time, because

we don’t know at what point during the nominal thread the

exception will occur.

There is a separate exception trajectory for each possible

exception.

Each catch interval has its own time-bounds

Note that the exception trajectories are uncontrolled


TPN Extensions:

Nominal Trajectory

[l0,u0]

[0,u0] [l1,u1]Exception-A Trajectory Catch-A Trajectory

[0,u0] [l2,u2]

Exception-B Trajectory Catch-B Trajectory

When checking consistency with the rest of the TPN, we compare each

thread of the try-catch block with the nominal trajectories in the rest of the

TPN. The extra work involved is O(nmc) where c is the number of

catch trajectories in the graph.

We never check consistency between two distinct catch

trajectories, thus we cannot handle multiple faults. However, the single-fault restriction helps

maintain tractability.


Analyzing Candidate Correctness

Dispatch Kernel






Macro Expansion

Exception Handling

CSPVariables

andDomains

Constraints

Dynamic CSP Solver

CSP problem updates

Candidate

When the CSP solver finds a candidate the Kernel analyzes it for correctness.

Analysis beings with Temporal Consistency

Checking.


Candidate Analysis: Temporal Consistency Check

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

TC Check Partial Solution

V1={ } V2={ } V3={ }

• Inconsistent if negative cycle found.

• Conflict summarizes inconsistency

• Conflicts used by CSP solver to focus candidate generation.



TPNDispatch Kernel






Macro Expansion

Exception Handling

TPN updates

TPN data

CSPVariables

andDomains

Constraints

Dynamic CSP Solver

CSP problem updates

partialsolutions

Second analysis is Tell Consistency Checking.


Candidate Analysis: Tell Consistency Check

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

Tell(A=y)

Tell(A=x)

V7={ , } V7

Tell(B=x)

Tell(B=y)

Tell Consist CheckPartial Solution

V1={ } V2={ } V6={ }

Possible Overlap!!

Orders mutually exclusive Tells so they can not co-occur.


Candidate Analysis

TPNDispatch Kernel






Macro Expansion

Exception Handling

TPN updates

TPN data

CSPVariables

andDomains

Constraints

Dynamic CSP Solver

CSP problem updates

partialsolutions

Third analysis is Ask Consistency Checking.

• Ensures that some Tell achieves each Ask.


Tell(B=y)

Candidate Analysis: Ask Achievement Check

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

Tell(A=y)

Tell(A=x)

V7={ , }

V7

Tell(B=x)

Ask(B=x)


Partial Solution

V1={ }Phase 1: Create Ask Variables

Phase 2: Populate Ask Domains

V8

V8={ }

When we detect an Ask, we create a new CSP variable.

The Ask variable’s domain is empty, because we have

not yet identified any satisfying Tells


V8={ }

Tell(B=y)

Start End

V1={ }

VI={V1}

V2={ , }V3={ , }V4={ , }

V2

V3

V4

Initial Variables

Variables

Constraints

V5={ }

V5

V6={ }

V6

Tell(A=y)

Tell(A=x)

V7={ , }

V7

Tell(B=x)

Ask(B=x)

V8


Partial Solution

V1={ }

V4={ }

Phase 1: Create Ask Variables

Phase 2: Populate Ask Domains

When a Tell is detected that could satisfy an Ask,

containment arcs are added to the TPN, and a domain

assignment is added to the Ask’s CSP variable.

Candidate Analysis: Ask Achievement Check


Model-Based Executive Architecture

SPlant

Obs Cntrl

Model-basedEmbedded Programs

S

ContinuousReactive

Commanding

Continuous Mode/StateEstimation

Model

Desiderata: languages that are:Suspicious

Monitor intentions and procedures

Self-AdaptiveExploits and generates contingencies

State and Fault AwareAnticipatory

“Model-predictive languages”Plans and verifies into the futurePredicts future states

Plans contingencies

Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul...

Documents

Transcript of Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul...