Presentation is loading. Please wait.

Presentation is loading. Please wait.

Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul Robertson MIT Computer Science and Artificial Intelligence.

Similar presentations


Presentation on theme: "Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul Robertson MIT Computer Science and Artificial Intelligence."— Presentation transcript:

1 Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul Robertson MIT Computer Science and Artificial Intelligence Laboratory

2 1/27/05SRS PI Meeting2 Overview Technical 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.

3 1/27/05SRS PI Meeting3 Expected Achievements Enable: 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.

4 1/27/05SRS PI Meeting4 Task Schedule. IDID Task Name20042005 JulJul AugAug SepSep OctOct NovNov DecDec JanJan FebFeb MarMar AprApr MayMay JunJun JulJul AugAug SepSep OctOct NovNov DecDec 1Testbed instrumentation for observation and control 2Languages and development tools 3Communicating model- based executives 4Method deprecation 5Method regeneration 6Decision theoretic method dispatch 7Testbed integration and modeling

5 1/27/05SRS PI Meeting5 Outline Overview Recap Language Design –Representing component behavior –Representing redundant timed methods Implementing model-predictive dispatch

6 1/27/05SRS PI Meeting6 Model-Based Executive Architecture S Plant Obs Cntrl Model-based Embedded Programs S Continuous Reactive Commanding Continuous Mode/State Estimation Model Desiderata: languages that are: Suspicious Monitor intentions and procedures Self-Adaptive Exploits and generates contingencies State and Fault Aware Anticipatory “Model-predictive languages” Plans and verifies into the future Predicts future states Plans contingencies

7 1/27/05SRS PI Meeting7 Rover test bed Allows real-world testing of robustness through model-based execution Consists of a reconfigurable environment with one ATRV- 2 and three ATRV-JRs.

8 1/27/05SRS PI Meeting8 Language Design Basic Constructs Expressing component behavior –Stochastic behavior Expressing timed, redundant methods –Multiple methods –Temporal relations –Exceptions

9 1/27/05SRS PI Meeting9 RMPL to PHCA encoding A always { A } A c if (c) { A } A c unless (c) { A } B parallel { A; B } A c c

10 1/27/05SRS PI Meeting10 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]; }

11 1/27/05SRS PI Meeting11 Probabilistic Transitions A B C p q r choose with probability: p { A } with probability: q { B } with probability: r {C }

12 1/27/05SRS PI Meeting12 Rendezvous Rescue Area Corridor 2 Corridor 1 Enroute RMPL Example: Redundant Timed Methods

13 1/27/05SRS PI Meeting13 RMPL for Group-Enroute method 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 }

14 1/27/05SRS PI Meeting14 RMPL for Group-Enroute method 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:

15 1/27/05SRS PI Meeting15 RMPL for Group-Enroute method 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 } Sequentiality: Concurrency:

16 1/27/05SRS PI Meeting16 RMPL for Group-Enroute method 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 } Conditionality and Preemption:

17 1/27/05SRS PI Meeting17 RMPL for Group-Enroute method 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 } Temporal Constraints:

18 1/27/05SRS PI Meeting18 RMPL for Group-Enroute method 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-deterministic choice:

19 1/27/05SRS PI Meeting19 Temporal Relations Between Concurrent Sub-Processes Add ability to relate arbitrary RMPL sub-processes endof(A) > startof(B) startof(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) A B A B AB A B AB A B A B

20 1/27/05SRS PI Meeting20 Scoped Labeling of Sub-Processes Added RMPL constructs: – : Gives a label to an RMPL sub-process Eg: ‘x’: [l,u] A –constrained temporal constraints Scoping: Constraints only refer to labels within sub-process. –temporal constraints: Temporally relates two sub-processes [l,u] A Label ‘x’

21 1/27/05SRS PI Meeting21 Example: Temporal Constraint constrained parallel { sequence { A; b: B }; sequence { C; d: D } } startof(b) ≤ startof(d) AB C D [0,+INF] Label ‘b’ Label ‘d’

22 1/27/05SRS PI Meeting22 Example: Metric Constraint Example: constrained parallel { sequence { A; b: B }; sequence { c: C; D } } endof(c) - startof(b) in [10,20] AB C D [10,20] Label ‘b’ Label ‘c’

23 1/27/05SRS PI Meeting23 Exceptions try { A } catch e1 { B } catch e2 { C } catch e3 { D } throw exceptionname B C D A e1 e2 e3

24 1/27/05SRS PI Meeting24 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 Commands Observables Mode Estimation Reactive Commanding Model of Subsystems monitor activitiesmonitor activities diagnose failuresdiagnose failures

25 1/27/05SRS PI Meeting25 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

26 1/27/05SRS PI Meeting26 Temporal Plan Network Example: Enroute Activity 1 45 8 910 13 2 1112 Enroute Group TraverseGroup Wait Group Transmit Activity (or sub-activity) Target Start with flexible plan representation

27 1/27/05SRS PI Meeting27 1 45 8 2 Enroute [450,540] [405, 486] Group TraverseGroup Wait Group Transmit [0, 54] [0, 2] Activity (or sub-activity) Duration (temporal constraint) [0, ] [0, 0] Target Start with flexible plan representation Temporal Plan Network Example: Enroute Activity

28 1/27/05SRS PI Meeting28 3 1 45 8 2 Enroute [450,540] Group Traverse [405, 486] Group TraverseGroup Wait Group Transmit [0, 54] [0, 2] Activity (or sub-activity) Duration (temporal constraint) [0, ] [0, 0] Target Add conditional nodes Conditional node Temporal Plan Network Example: Enroute Activity

29 1/27/05SRS PI Meeting29 3 1 45 8 910 13 2 671112 Enroute [450,540] Group Traverse [405, 486] Group TraverseGroup Wait Group Transmit [0, 54] [0, 2] Activity (or sub-activity) Duration (temporal constraint) [0, ] [0, 0] Ask( PATH1 = OK) Ask( PATH2 = OK) Ask( EXPLORE = OK) Target Add temporally extended, symbolic constraints Symbolic constraint (Ask,Tell) Conditional node Temporal Plan Network Example: Enroute Activity

30 1/27/05SRS PI Meeting30 Planning Group-Enroute 3 6 4 5 [405,486] Ask(PATH1=OK) 12 7 Ask(PATH2=OK) 8 [405,486] [450,540] Ask(PROCEED) 1 9 1010 [0,54] 1212 1313 [0,2] [0,  ] 1415 Tell(PATH1=OK) [450,450] 1617 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 Wait Group Transmit Target

31 1/27/05SRS PI Meeting31 Generates Schedulable Plan 3 6 4 5 [405,486] Ask(PATH1=OK) 12 7 Ask(PATH2=OK) 8 [405,486] [450,540] Ask(PROCEED) 11 9 10 [0,54] 12 13 [0,2] [0,  ] 1415 Tell(PATH1=OK) [450,450] 1617 Tell(PROCEED) [200,200] s e [500,800] [10,10] [0,  ] Group-Enroute Group Traverse Group Wait Group Transmit Target Trace consistent trajectories Check Schedulability Satisfy and Protect Asks To Plan: Instantiate Group-Enroute Add External Constraints

32 1/27/05SRS PI Meeting32 Satisfying Asks Find equivalent overlapping tell Link ask to tell. Constrain tell to contain ask. 5 789 101112 6 {4,6} {6,9} {5,8}{7,11} {7,10} {8,11} ask(c) tell(c)

33 1/27/05SRS PI Meeting33 Avoiding Threats Identify overlapping Inconsistent tells. Promote or demote. 5 789 101112 6 {4,6} {6,9} {5,8}{7,11} {7,10} {8,11} tell(c) tell(  c) [0,infb]

34 1/27/05SRS PI Meeting34 Architecture Walkthrough RMPL RMPL Compiler TPN Macro Library 1.The human writes a program in RMPL. 2.The RMPL program is compiled into Temporal Plan Network (TPN) fragments.

35 1/27/05SRS PI Meeting35 Architecture Walkthrough RMPL RMPL Compiler TPN Macro Library Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask Achievement Check Location Consistency Check Macro Expansion Exception Handling Executive plan updates exceptions TPN TPN Graph Algorithms Common Data Repository Suite of Algorithms FIFO SSSP SDSP APSP TPN updates processed TPN data TPN data Conditional CSP Variables and Domains Constraints Conditional CSP Solver CSP problem updates partial solutions

36 1/27/05SRS PI Meeting36 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 V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints initialize

37 1/27/05SRS PI Meeting37 StartEnd Step 2: Create variables and constraints corresponding to the non-causal link constraint arcs V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 initialize Initialize: Create CSP for TPN

38 1/27/05SRS PI Meeting38 StartEnd We are left with a CSP that can be sent to the dynamic CSP solver V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 initialize Initialize: Create CSP for TPN

39 1/27/05SRS PI Meeting39 Architecture Walkthrough TPN Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask Achievement Check Location Consistency Check Macro Expansion Exception Handling TPN updates TPN data CSP Variables and Domains Constraints Dynamic CSP Solver CSP problem updates partial solutions 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. Executive plan updates exceptions

40 1/27/05SRS PI Meeting40  V 8 ={ } Tell(B=y) Exception Handling StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 Tell(A=y) Tell(A=x) V 7 ={, } V 7 Tell(B=x) Ask(B=x) V 8 Ask Consistency Check 1.Execution begins… 2.An error occurs, and an exception is thrown Partial Solution V 1 ={ } V 4 ={ } V 2 ={ } V 5 ={ } V 3 ={ } V 8 ={ } EXCEPTION

41 1/27/05SRS PI Meeting41 Ask Consistency Check 1.Execution begins… 2.An error occurs, and an exception is thrown 3.The exception-handling code is inserted EXCEPTION handler delay The handler is the TPN sub-process corresponding 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

42 1/27/05SRS PI Meeting42  V 8 ={ } Tell(B=y) StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 V 7 ={, } V 7 Tell(B=x) Ask(B=x) V 8 Ask Consistency Check Partial Solution V 1 ={ } V 4 ={ } V 2 ={ } V 5 ={ } V 3 ={ } V 8 ={ } EXCEPTION 1.Execution begins… 2.An error occurs, and an exception is thrown 3.The exception-handling code is inserted 4.Replanning begins, pre-selecting anything that has already been executed Exception Handling

43 1/27/05SRS PI Meeting43 TPN Extensions: Try-Catch Block This new node design denotes the start of a try-catch block

44 1/27/05SRS PI Meeting44 TPN Extensions: Try-Catch Block Nominal Trajectory [l 0,u 0 ] The nominal trajectory has a lower and upper-timebound as usual

45 1/27/05SRS PI Meeting45 TPN Extensions: Try-Catch Block Nominal Trajectory [l 0,u 0 ] [0,u 0 ][l 1,u 1 ] Exception-A Trajectory Catch-A Trajectory [0,u 0 ][l 2,u 2 ] Exception-B Trajectory Catch-B Trajectory Each exception trajectory can take from 0 to u 0 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

46 1/27/05SRS PI Meeting46 TPN Extensions: Nominal Trajectory [l 0,u 0 ] [0,u 0 ][l 1,u 1 ] Exception-A Trajectory Catch-A Trajectory [0,u 0 ][l 2,u 2 ] 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.

47 1/27/05SRS PI Meeting47 Analyzing Candidate Correctness Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask Achievement Check Location Consistency Check Macro Expansion Exception Handling CSP Variables and Domains 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.

48 1/27/05SRS PI Meeting48 Candidate Analysis: Temporal Consistency Check StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 TC Check Partial Solution V 1 ={ }V 2 ={ }V 3 ={ } Inconsistent if negative cycle found. Conflict summarizes inconsistency Conflicts used by CSP solver to focus candidate generation.

49 1/27/05SRS PI Meeting49 Architecture Walkthrough TPN Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask Achievement Check Location Consistency Check Macro Expansion Exception Handling TPN updates TPN data CSP Variables and Domains Constraints Dynamic CSP Solver CSP problem updates partial solutions Second analysis is Tell Consistency Checking.

50 1/27/05SRS PI Meeting50 Candidate Analysis: Tell Consistency Check StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 Tell(A=y) Tell(A=x) V 7 ={, } V 7 Tell(B=x) Tell(B=y) Tell Consist Check Partial Solution V 1 ={ }V 2 ={ }V 6 ={ } Possible Overlap!! Orders mutually exclusive Tells so they can not co-occur.

51 1/27/05SRS PI Meeting51 Candidate Analysis TPN Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask Achievement Check Location Consistency Check Macro Expansion Exception Handling TPN updates TPN data CSP Variables and Domains Constraints Dynamic CSP Solver CSP problem updates partial solutions Third analysis is Ask Consistency Checking. Ensures that some Tell achieves each Ask.

52 1/27/05SRS PI Meeting52 Tell(B=y) Candidate Analysis: Ask Achievement Check StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 Tell(A=y) Tell(A=x) V 7 ={, } V 7 Tell(B=x) Ask(B=x) Ask Consistency Check Partial Solution V 1 ={ } Phase 1: Create Ask Variables Phase 2: Populate Ask Domains V 8 V 8 ={ } 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

53 1/27/05SRS PI Meeting53  V 8 ={ } Tell(B=y) StartEnd V 1 ={ } V I ={V 1 } V 2 ={, } V 3 ={, } V 4 ={, } V 2 V 3 V 4 Initial Variables Variables Constraints V 5 ={ } V 5 V 6 ={ } V 6 Tell(A=y) Tell(A=x) V 7 ={, } V 7 Tell(B=x) Ask(B=x) V 8 Ask Consistency Check Partial Solution V 1 ={ } V 4 ={ } 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

54 1/27/05SRS PI Meeting54 Model-Based Executive Architecture S Plant Obs Cntrl Model-based Embedded Programs S Continuous Reactive Commanding Continuous Mode/State Estimation Model Desiderata: languages that are: Suspicious Monitor intentions and procedures Self-Adaptive Exploits and generates contingencies State and Fault Aware Anticipatory “Model-predictive languages” Plans and verifies into the future Predicts future states Plans contingencies

55 1/27/05SRS PI Meeting55 Demonstration scenario End to End Self-regeneration of Command & Control Systems: Robot must plan and execute motion to one or more targets. Robot must perform designated tasks at selected destinations. Robot utilizes various sensors and actuators in achieving its task. Robot utilizes various software components in interpreting its sensor data and manipulating its actuators. Changing environment will cause software components to fail. Failed software components will be detected and diagnosed. Alternate configurations of the software will be found that can maintain mission objectives while maximizing utility—in real- time. Fault injection testing: We will inject faults into the test bed including (1) environment changes, (2) incompatibilities, (3) software attacks.


Download ppt "Pervasive Self-Regeneration through Concurrent Model-Based Execution Brian Williams (PI) Paul Robertson MIT Computer Science and Artificial Intelligence."

Similar presentations


Ads by Google