1 / 54

Pervasive Self-Regeneration through Concurrent Model-Based Execution

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

gordon
Download Presentation

Pervasive Self-Regeneration through Concurrent Model-Based Execution

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview Technical Objective: When software fails, because of (a) environmentchanges (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. SRS PI Meeting

  3. 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. SRS PI Meeting

  4. 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 . SRS PI Meeting

  5. Outline • Overview • Recap • Language Design • Representing component behavior • Representing redundant timed methods • Implementing model-predictive dispatch SRS PI Meeting

  6. Model-Based Executive Architecture Model Continuous Mode/State Estimation Continuous Reactive Commanding • 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 Model-basedEmbedded Programs S Obs Cntrl S Plant SRS PI Meeting

  7. Rover test bed Consists of a reconfigurable environment with one ATRV-2 and three ATRV-JRs. Allows real-world testing of robustness throughmodel-based execution SRS PI Meeting

  8. Language Design • Basic Constructs • Expressing component behavior • Stochastic behavior • Expressing timed, redundant methods • Multiple methods • Temporal relations • Exceptions SRS PI Meeting

  9. RMPL to PHCA encoding always { A } A c c if (c) { A } A c unless (c) { A } parallel { A; B } A A B c SRS PI Meeting

  10. 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]; } SRS PI Meeting

  11. Probabilistic Transitions choose with probability: p { A } with probability: q { B } with probability: r {C } A p q B r C SRS PI Meeting

  12. RMPL Example: Redundant Timed Methods Enroute Corridor 2 Rendezvous Rescue Area Corridor 1 SRS PI Meeting

  13. 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 } } } SRS PI Meeting

  14. 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: SRS PI Meeting

  15. 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: SRS PI Meeting

  16. 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: SRS PI Meeting

  17. 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: SRS PI Meeting

  18. 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: SRS PI Meeting

  19. Temporal Relations Between Concurrent Sub-Processes • Add ability to relate arbitrary RMPL sub-processes A endof(A) > startof(B) B startof(A) < startof(B), endof(A) > endof(B) A B endof(A) = startof(B) A B endof(A) > endof(B) A B endof(A) < startof(B) A B startof(A) < startof(B) A B A startof(A) = startof(B), endof(A) = endof(B) B SRS PI Meeting

  20. 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’ SRS PI Meeting

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

  22. Example: Metric Constraint • Example: constrained parallel { sequence { A;b: B }; sequence {c: C; D } } endof(c) - startof(b) in [10,20] A B Label ‘b’ [10,20] Label ‘c’ D C SRS PI Meeting

  23. Exceptions try { A } catch e1 { B } catch e2 { C } catch e3 { D } throw exceptionname A e1 B e2 C e3 D SRS PI Meeting

  24. Incorporating Model-Predictive Method Selection RMPL Program Reactive Temporal Planner Plan Runner (Hidden) States Model of Subsystems • monitor activities • diagnose failures Mode Estimation Reactive Commanding Observables Commands Dynamically selects consistent methods over future horizon, Adapts to uncertainty by selecting execution times dynamically, monitors outcomes and plans contingencies. SRS PI Meeting

  25. Selecting Methods over a Horizon RMPL Compiler Temporal Plan Network (TPN) Reactive Temporal Planner • Selects schedulable execution threads of TPN • Represents all RMPL executions over horizon Concurrent Plan • Plan = Execution threads related by Simple Temporal Net Reactive Model-based Programming Language SRS PI Meeting

  26. Temporal Plan Network Example: Enroute Activity • Start with flexible plan representation Enroute 1 2 Group Traverse Group Wait 4 5 9 10 Target 8 13 Group Transmit 11 12 Activity (or sub-activity) SRS PI Meeting

  27. Temporal Plan Network Example: Enroute Activity • Start with flexible plan representation Enroute[450,540] 1 2 [0, 0] [0, 0] Group Traverse Group Wait 4 [405, 486] 5 [0, 54] [0, 0] [0, 0] [0, 0] Target 8 [0, 0] Group Transmit [0, ] [0, 2] Activity (or sub-activity) Duration (temporal constraint) SRS PI Meeting

  28. Temporal Plan Network Example: Enroute Activity • Add conditional nodes Enroute[450,540] 1 2 [0, 0] [0, 0] Group Traverse Group Wait 4 [405, 486] 5 [0, 54] [0, 0] [0, 0] [0, 0] [0, 0] Target 8 3 [0, 0] [0, 0] Group Traverse Group Transmit [0, ] [0, 0] [405, 486] [0, 2] Activity (or sub-activity) Duration (temporal constraint) Conditional node SRS PI Meeting

  29. Temporal Plan Network Example: Enroute Activity • Add temporally extended, symbolic constraints Enroute[450,540] 1 2 [0, 0] [0, 0] Group Traverse Group Wait 4 [405, 486] 5 9 [0, 54] 10 [0, 0] [0, 0] [0, 0] [0, 0] Ask( PATH1 = OK) Ask( EXPLORE = OK) Target 8 13 3 [0, 0] [0, 0] Group Traverse Group Transmit [0, ] [0, 0] 6 [405, 486] 7 11 [0, 2] 12 Ask( PATH2 = OK) Activity (or sub-activity) Duration (temporal constraint) Conditional node Symbolic constraint (Ask,Tell) SRS PI Meeting

  30. Planning Group-Enroute [500,800] s e Tell(PATH1=OK) Tell(PROCEED) [10,10] [0,] 14 15 16 17 [450,450] [200,200] Group-Enroute [0,] [0,] [450,540] 1 2 Group Traverse Group Wait Ask(PATH1=OK) Ask(PROCEED) 4 9 5 10 [405,486] [0,54] Target 3 8 13 Group Traverse Group Transmit Ask(PATH2=OK) [0,] 6 7 11 12 [405,486] [0,2] • To Plan: • Instantiate Group-Enroute • Add External Constraints (Tells) SRS PI Meeting

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

  32. Satisfying Asks • Find equivalentoverlappingtell • Link ask to tell. • Constrain tell to contain ask. {4,6} {5,8} {7,11} ask(c) 7 8 9 5 6 {4,6} {8,11} 10 11 12 tell(c) {4,6} {6,9} {7,10} SRS PI Meeting

  33. Avoiding Threats [0,infb] • Identify overlapping Inconsistent tells. • Promote or demote. {4,6} {5,8} {7,11} tell(c) 7 8 9 5 6 {4,6} {8,11} 10 11 12 tell(c) {4,6} {6,9} {7,10} SRS PI Meeting

  34. Architecture Walkthrough TPN MacroLibrary RMPL RMPLCompiler • The human writes a program in RMPL. • The RMPL program is compiled into Temporal Plan Network (TPN) fragments. SRS PI Meeting

  35. Architecture Walkthrough TPN TPN updates CSP problem updates TPN data TPN data Conditional CSP TPN Graph Algorithms VariablesandDomains Constraints Suite of Algorithms processedTPNdata FIFO SSSP SDSP APSP Conditional CSP Solver Common DataRepository partialsolutions TPN MacroLibrary RMPL RMPLCompiler Dispatch Kernel Create Conditional CSP Temporal Consistency Check Tell Consistency Check Ask AchievementCheck Location Consistency Check Macro Expansion Executive plan updates Exception Handling exceptions SRS PI Meeting

  36. Initialize: Create CSP for TPN initialize  V2 V1={ } V2={ , } V3={ , } V4={ , }  V3  V4 Step 1: Walk the TPN and create variables corresponding to the decision nodes Initial Variables End Start VI={V1} Ask(B=x) Variables Tell(B=x) Tell(B=y) Constraints Tell(A=x) Tell(A=y) SRS PI Meeting

  37. Initialize: Create CSP for TPN initialize  V2 V6={ } V5={ } V1={ } V2={ , } V3={ , } V4={ , }  V3  V4  V5  V6 Step 2: Create variables and constraints corresponding to the non-causal link constraint arcs Initial Variables Start End VI={V1} Variables Constraints SRS PI Meeting

  38. Initialize: Create CSP for TPN initialize  V2 V6={ } V5={ } V1={ } V2={ , } V3={ , } V4={ , }  V3  V4  V5  V6 We are left with a CSP that can be sent to the dynamic CSP solver Initial Variables Start End VI={V1} Variables Constraints SRS PI Meeting

  39. Architecture Walkthrough • 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. TPN TPN updates Dispatch Kernel CSP problem updates TPN data Create Conditional CSP CSP VariablesandDomains Constraints Temporal Consistency Check Tell Consistency Check Ask AchievementCheck Dynamic CSP Solver Location Consistency Check partialsolutions Macro Expansion Executive plan updates Exception Handling exceptions SRS PI Meeting

  40. Exception Handling Ask Consistency Check  V2 V2={ } V4={ } V8={ } V3={ } V1={ } V1={ } V5={ } V8={ } V5={ } V6={ } V7={ , } V2={ , } V3={ , } V4={ , }  V3  V8  V4  V6  V7  V5  Partial Solution • Execution begins… • An error occurs, and an exception is thrown Initial Variables Start End VI={V1} EXCEPTION Ask(B=x) Variables Tell(B=x) Constraints Tell(B=y) Tell(A=x) Tell(A=y) SRS PI Meeting

  41. Exception Handling Ask Consistency Check • Execution begins… • An error occurs, and an exception is thrown • The exception-handling code is inserted 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 delay handler The handler is the TPN sub-processcorresponding to the RMPL “catch” statementthat matches the thrown exception SRS PI Meeting

  42. Exception Handling Ask Consistency Check  V2 V1={ } V6={ } V5={ } V1={ } V4={ } V5={ } V3={ } V8={ } V8={ } V2={ } V4={ , } V3={ , } V2={ , } V7={ , }  V3  V4  V8  V7  V5  V6  Partial Solution • Execution begins… • An error occurs, and an exception is thrown • The exception-handling code is inserted • Replanning begins, pre-selecting anything that has already been executed Initial Variables Start End VI={V1} EXCEPTION Ask(B=x) Variables Tell(B=x) Constraints Tell(B=y) SRS PI Meeting

  43. TPN Extensions: Try-Catch Block This new node design denotes the start of a try-catch block SRS PI Meeting

  44. TPN Extensions: Try-Catch Block Nominal Trajectory [l0,u0] The nominal trajectory has a lower and upper-timebound as usual SRS PI Meeting

  45. TPN Extensions: There is a separate exception trajectory for each possible exception. 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. Try-Catch Block Each catch interval has its own time-bounds Nominal Trajectory [l0,u0] [0,u0] [l1,u1] Catch-A Trajectory Exception-A Trajectory [0,u0] [l2,u2] Exception-B Trajectory Catch-B Trajectory Note that the exception trajectories are uncontrolled SRS PI Meeting

  46. TPN Extensions: 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. Nominal Trajectory [l0,u0] [0,u0] [l1,u1] Catch-A Trajectory Exception-A Trajectory [0,u0] [l2,u2] Exception-B Trajectory Catch-B Trajectory SRS PI Meeting

  47. Analyzing Candidate Correctness When the CSP solver finds a candidate the Kernel analyzes it for correctness. Dispatch Kernel CSP problem updates Create Conditional CSP CSP VariablesandDomains Constraints Temporal Consistency Check Tell Consistency Check Analysis beings with Temporal Consistency Checking. Ask AchievementCheck Dynamic CSP Solver Location Consistency Check Candidate Macro Expansion Exception Handling SRS PI Meeting

  48. Candidate Analysis: Temporal Consistency Check TC Check  V2 V6={ } V2={ } V1={ } V1={ } V5={ } V3={ } V4={ , } V3={ , } V2={ , }  V3  V4  V6  V5 • Inconsistent if negative cycle found. • Conflict summarizes inconsistency • Conflicts used by CSP solver to focus candidate generation. Partial Solution Initial Variables Start End VI={V1} Variables Constraints SRS PI Meeting

  49. Architecture Walkthrough Second analysis is Tell Consistency Checking. TPN TPN updates Dispatch Kernel CSP problem updates TPN data Create Conditional CSP CSP VariablesandDomains Constraints Temporal Consistency Check Tell Consistency Check Ask AchievementCheck Dynamic CSP Solver Location Consistency Check partialsolutions Macro Expansion Exception Handling SRS PI Meeting

  50. Candidate Analysis: Tell Consistency Check Tell Consist Check  V2 V5={ } V1={ } V6={ } V2={ } V6={ } V1={ } V2={ , } V3={ , } V7={ , } V4={ , }  V3  V4  V6  V5  V7 Orders mutually exclusive Tells so they can not co-occur. Partial Solution Initial Variables Start End VI={V1} Variables Tell(B=x) Constraints Tell(B=y) Tell(A=x) Tell(A=y) Possible Overlap!! SRS PI Meeting

More Related