Pervasive Self-Regeneration through Concurrent Model-Based Execution

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

2. Outline • What we are trying to do. • Demonstration scenario and test bed. • Implications of successful results. • Technical approach. • What is new. • Anticipated challenges. • Technology transition. • Looking forward: next steps.

3. What we are trying to do • Why software fails: • Software assumptions about the environment become invalid because of changes in the environment. • Software changes introduce incompatibilities. • Software is attacked by a hostile agent. • What can be done when software fails: • Recognize that a failure has occurred. • Diagnose what has failed – and why. • Find an alternative way of achieving the intended behavior. Runtime Models

4. Building upon a proven technology base. • By extending RMPL to support software failure, we can extend robustness in the face of hardware failures to robustness in the face of software failures. • Many of the same issues pertain: • Detection of faulty behavior • Diagnosis of the fault given faulty behavior • Reconfiguration of the software to achieve intended behavior using different software components. • Select among alternatives to maximize utility.

5. Deliverables • Model-based programming tools • A language for modeling (RMPL): • The process in terms of desired state evolutions; • The components; and • The environment. • Model-based executives that provide: • Safe optimal dispatch. • Redundant methods. • Continuous monitoring and diagnosis. • Regeneration and optimization.

6. Architectural overview Model Continuous Mode/State Estimation Continuous Reactive Commanding • Desiderata: languages that are • Suspicious • Monitor intentions and plans • 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

7. Basic assumptions for our approach • Objectives for the RMPL language • Low overhead • The effort required of the programmers to achieve robustness should be small compared to the effort required to implement the base capability. • Pervasive • The technology should be applied not only to major components but to all components in the system. • Incremental • Increased robustness can be achieved incrementally by adding greater modeling.

8. Innovative claims • Features of our approach: • Fault-aware processes. • Fault-adaptive. • Model-based. • Synthesizes a fault-adaptive process to achieve state evolutions. • Reasons from MODELS of correct and faulty behavior of supporting service components. • Constructs novel recovery actions in the face of novel faults. • Specific approaches: • Dynamic selection from redundant methods. • Self-optimization: select the optimal candidates. • Continuous monitoring. • Incremental addition of robustness by adding monitoring procedures incrementally. • Synthesis of repair procedures from models.

9. 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.

10. Test bed summary • Robot scenario involves: • Path planning and execution. • Goal selection with risks and rewards. • Visual and other sensors and actuators utilized in navigation and task execution. • Reacts to: • Failures in the software. • Exploiting redundant methods. • By re-planning to maintain optimality. • Discoveries in the environment. • Obstacles • Suitability of using selected sensors given terrain lighting etc. • Attack

11. Rover test bed Consists of a reconfigurable environment with one ATRV-2 and three ATRV-JRs. Allows real-world testing of planning and execution software

12. Rover test bed setup SICK LMS 200 laser scanner Stereo camera 802.11a wireless network adapter Sonar control board Ethernet card rFLEX controller Firewire card ttyR ports Right motor Serial port Left motor rFLEX screen Onboard PC  Inclinometer Sonar sensors GPS receiver Stereo camera Compass Inclinometer Antennas for wireless LAN Laser range scanner Sonar sensors Wheel encoders (odometry) Differential drive • Sensors give information on motion and environment. • Onboard PC allows for real-time computation and command processing.

13. Implications of successful results • Robotic 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 detects and recovers from software attacks. • Modeling attack scenarios • Software that automatically improves as better software components and models are added. • Higher level of command and control for robotic missions.

14. Military roles for autonomous robots • Reconnaissance • Rover makes its way to designated places and reports back—such as with pictures. • Search and Rescue • Rover enters a dangerous area and reports back on the presence of wounded people. • Mapping • Rover explores (a building) producing a map annotated with pictures in support of ground forces. • Munitions Delivery • Rover goes to designated locations and delivers munitions. (like predator UAV)

15. Technical approach • We will extend the technology developed for execution, hardware fault detection, diagnosis and reconfiguration successfully used in Deep Space One to be applied to software fault awareness and reconfiguration. • Software components look like hardware components but reconfiguration is less restricted. • A greater emphasis on environment modeling is necessary because most software faults will be because of environmental changes.

16. Systems Should be Suspicious Robust Systems Should be Fully State Aware And Should Use To Dynamically Monitor Specifications Model Continuous Estimation of Modes and State Real Time Traditional Commanding is Open Loop • Sensor Interpretation: • Nominal: • Command Confirmation • Fault Detection • Failure: • Fault Isolation • Fault Diagnosis

17. Commanding InvolvesRepairing a Correct State Robust systems should select the best action in context Model Continuous Mode/State Estimation Continuous Reactive Commanding Nominal commanding is Traditionally pre-determined • For long-lived systems, failure is the rule: • Must navigate around failures. • Must operate with varying resources and capabilities. • Should select best means amongst multiple alternatives.

18. How Do We Guide Self-Regenerative Systems? - By Interacting Directly with State Embedded Program Model-basedEmbedded Program Obs Cntrl S Services S Services Model-based programs interact with state Embedded programs interact with sensors and actuators. Programmers map between sensors, actuators to states. Model-based executives map between sensors, actuators to states.

19. Model-based Programs Interact Directly with State State estimates State goals Mode Estimation Reactive Commanding Fault Occurs Current Belief State Reconfigure least cost reachable goal state First Action Model-basedEmbedded Programs S RMPL • State assertion • State query • Conditional Execution • Preemption • Iteration • Concurrent execution Plant Model Model-based Executive Obs Cntrl S Plant

20. Model-based Autonomy Architecture Executive Mission Manager Planner/ Scheduler Model-based Fault Protection Ground System Real-Time Execution RAX Manager Flight H/W Fault Monitors Planning Experts (incl. Navigation)

21. Model-based Autonomy Architecture Goal States Remote Agent Ground System Executive Mission Manager Real-Time Execution Planner/ Scheduler Model-based Fault Protection RAX Manager Flight H/W Fault Monitors Planning Experts (incl. Navigation)

22. Model-based Autonomy Architecture Remote Agent Ground System Executive Mission Manager Real-Time Execution Planner/ Scheduler Model-based Fault Protection RAX Manager Flight H/W Fault Monitors Planning Experts (incl. Navigation)

23. Model-based Autonomy Architecture Remote Agent Ground System Procedural Executive Mission Manager Real-Time Execution Planner/ Scheduler Model-based Fault Protection Low-Level Fault Protection RAX Manager Flight H/W Fault Monitors Planning Experts (incl. Navigation)

24. Model-based Autonomy Architecture Remote Agent Ground System Procedural Executive Mission Manager High-Level Fault Protection Real-Time Execution Planner/ Scheduler Model-based Executive RAX Manager Flight H/W Fault Monitors Planning Experts (incl. Navigation)

25. Remote Agent ExperimentMay, 1999 May 17-18th experiment: High-level Fault Protection • Generate plan for course correction and thrust • Diagnose camera as stuck on • Power constraints violated, abort current plan and replan • Perform optical navigation • Perform ion propulsionthrust May 21th experiment: Low-level Fault Protection • Diagnose faulty device and • Repair by issuing reset. • Diagnose switch sensor failure. • Determine harmless, and continue plan. • Diagnose thruster stuck closed and • Repair by switching to alternate method of thrusting. • Back to back planning RA was a toolbox, want a seamless language

26. Technology transition • The structure of our solution facilitates transition. • Implements self-regenerative system using language+executive, as opposed to a set of regeneration utilities. • Easily wraps self-regeneration around existing components, through a clean separation of the “executive” and “plant.” • Has supported a long history of successful technology transition. • Papers and other publications

27. Looking forward: next steps • Reasoning about complex software models. • Coordination while preserving privacy of subsystem information. • Extending the technology to work with complex distributed self-regenerative systems. • Regeneration requires peer to peer coordination of systems. • Subtle faults that are distributed across multiple systems. • Faults that are detected in systems in which we do not have direct control—and must negotiate fault resolution.

28. Appendix A

29. Model-based Execution Kernels as Stochastic Optimal Controllers Goal States Model Deductive Controller s’(t) mode reconfiguration mode estimation commands(t) Observations(t) Plant s(t) g f

30. Diagnosis Operators and programmers reason through system-wide interactions to: • isolate faults • diagnose causes

31. OPSAT • Generate Most-likely Candidate Diagnoses: • conflict-directed A* (< 10 states visited) • Test Against Model and Observables: • Incremental Satisfiability (avg. < 10 % off ideal) • Learn from counter examples (conflicts) to guide generation. Optimal feasible modes ISAT Checked kernel Conflict- directed A* Conflict

32. Compare Most Likely Candidate to Observations Helium tank Oxidizer tank Fuel tank Flow1 = zero Pressure1 = nominal Pressure2= nominal Main Engines Acceleration = zero

33. Isolate Conflicting Modes Helium tank Oxidizer tank Fuel tank Flow 1= zero Main Engines A conflict, C, is an assignment to a subset of the mode variables that is inconsistent with the model and observations.

34. Generate Next Most Likely Candidate Helium tank Oxidizer tank Fuel tank Flow 1= zero Main Engines Every consistent mode assignment must differ from the conflict for at least one mode variable

35. Generate Next Most Likely Candidate Helium tank Oxidizer tank Fuel tank Main Engines Every consistent mode assignment must differ from the conflict for at least one mode variable

36. Testing Candidate Detects Another Conflict Helium tank Oxidizer tank Fuel tank Pressure1 = nominal Pressure2= nominal Main Engines Acceleration = zero

37. Generate Next Most Likely Candidate Helium tank Oxidizer tank Fuel tank Pressure1 = nominal Pressure2= nominal Main Engines Acceleration = zero Consistent mode assignment must differ from both conflicts

38. Consistent: Most Likely Diagnosis Helium tank Oxidizer tank Fuel tank Pressure1 = nominal Flow1 = zero Pressure2= nominal Flow2 = positive Main Engines Acceleration = zero

39. Diagnosis Configuration Management Operators and programmers reason through system-wide interactions to: • isolate faults • diagnose causes • repair • reconfigure

40. Conflicts Focus MR Goal: Achieve Thrust Find least cost modes that entail the current goal. • A conflict, C, is an assignment to a subset of the mode variables that entails the negation of the goal.

41. Conflicts Focus MR Goal: Achieve Thrust Find least cost modes that entail the current goal. • A conflict, C, is an assignment to a subset of the mode variables that entails the negation of the goal.

42. Conflicts Focus MR Goal: Achieve Thrust Find least cost modes that entail the current goal. • A conflict, C, is an assignment to a subset of the mode variables that entails the negation of the goal.

43. Models are Concurrent, Constraint Encodings of Partially Observable Markov Decision Process Stuck open Open Open Close Cost 5 Prob .9 Stuck closed Closed vlv=stuck open => [Outflow]S = [Inflow]S and [Outflow]R = [Inflow]R vlv=open => [Outflow]S = [Inflow]S and [Outflow]R = [Inflow]R Vlv = closed => Outflow = 0; Unknown vlv=stuck closed=> Outflow = 0; • One automaton for each device. • Communication through shared variables.

44. Estimating Modes Operators and programmers reason through system-wide interactions to: • isolate faults • diagnose causes • monitor • confirm commands • track goals

45. Mode Estimation Find most likely reachable states consistent with observations. Left engine on Observe “no thrust” Enumerated by decreasing probability. Every component transitions at each time step.

46. Estimating Modes Controlling Modes Operators and programmers reason through system-wide interactions to : • monitor • track goals • confirm commands • isolat faults • diagnose faults • repair • reconfigure • execute • avoid failures • change control policies

47. Model-based Reactive Planning • Find least cost state that entails the current goal and is reachable from the current state. • Find first action that moves towards this state. Configuration goals Mode Est. Mode Reconf. Reactive Planning current state goal state Model Command Burton Model-based Executive IJCAI97

48. Architectural overview Model Continuous Mode/State Estimation Continuous Reactive Commanding • Desiderata: languages that are • Suspicious • Monitor intentions and plans • 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

49. Anticipated Challenges • Software is harder than hardware: • Hardware recovers by leveraging backups, while software leverages alternative methods. • Models of software are more complex to specify. • While hardware’s topology is static, software’s topology dynamically changes. • Performance • Software systems result in larger state spaces, making real-time response a challenge.