what we are trying to do
play

What we are trying to do Supporting Automatic Why software fails: - PDF document

Sep 19, 2022 •151 likes •219 views

A Model-Based System What we are trying to do Supporting Automatic Why software fails: Self-Regeneration of Critical Software assumptions about the environment Software become invalid because of changes in the environment. Paul

  1. A Model-Based System What we are trying to do Supporting Automatic • Why software fails: Self-Regeneration of Critical – Software assumptions about the environment Software become invalid because of changes in the environment. Paul Robertson & Brian Williams – Software is attacked by a hostile agent. – Software changes introduce incompatibilities. Model-Based and Embedded Robotic Systems • What can be done when software fails: http://mers.mit.edu Runtime – Recognize that a failure has occurred. Models – Diagnose what has failed – and why. MIT Computer Science and Artificial Intelligence Laboratory – Find an alternative way of achieving the intended behavior. 5/19/05 SelfMan 2005 2 Self repairing explorer: Deep Space 1 Flight Experiment, May 1999. courtesy ARC & JPL Cassini Saturn Probe 5/19/05 SelfMan 2005 3 Project Status Overview Funding: DARPA (SRS), NASA (Ames) Technical Objective: Current State: Prototype System Operational When software fails because (a) environment changes (b) software incompatibility (c) hostile attack, (1) Project Premise: recognize that a failure has occurred, (2) diagnose Extend proven approach to hardware diagnosis what has failed and why, and (3) find an alternative and repair as used in DS-1 to critical software. way of achieving the intended behavior. Principle Ideas: Technical approach: Model-Based Language Approach By extending RMPL to support software failure, we can extend robustness in the face of hardware failures to Redundant Methods robustness in the face of software failures. This Method Deprecation involves: (1) Detection Model-Predictive Dispatch RMPL Models of: (2) Diagnosis Software Components, Hierarchical Models Component Hierarchy & Interconnectivity, (3) Reconfiguration and Correct Behavior. Adjustable Autonomy (4) Utility Maximization . 5/19/05 SelfMan 2005 5 5/19/05 SelfMan 2005 6 1

  2. Expected Benefits What can go wrong? 1. Hardware: A problem with robot hardware. • Software systems that can operate autonomously to achieve goals in complex and 2. Software: A problem with the environment. changing environments. 1. A mismatch between a chosen algorithm and the – Modeling environment environment such as there not being enough light to support processing of a color image. • Software that detects and works around “bugs” resulting from incompatible software changes. 2. An unexpected imaging problem such as an obstruction to the visual field (caused by a large – Modeling software components obscuring rock). • Software that detects and recovers from Solution to 2.1 software attacks. Solution to 2.2 – Modeling attack scenarios Reconfigure the software structure: Switch to a contingent plan: • Software that automatically improves as better 1. Redundant Methods 1. Exception software components and models are added. 2. Mode Estimation 2. Model Predictive Dispatch 3. Mode Reconfiguration 3. Replanning 5/19/05 SelfMan 2005 7 5/19/05 SelfMan 2005 8 Science Target Search Test Bed Platform Scenario Involves: Cooperative use of multiple robots. Timing critical software. Reconfiguration of Software Components. Multiple Redundant Methods • Cooperatively search for targets in the predefined Continuous Replanning regions Multiple Redundant Methods • Search from predefined viewpoints • Search for the targets using stereo cameras and various visualization algorithms 5/19/05 SelfMan 2005 9 5/19/05 SelfMan 2005 10 Science Target Search Science Target Search Scenario Scenario 5/19/05 SelfMan 2005 11 5/19/05 SelfMan 2005 12 2

  3. Science Target Search Method Regeneration: Scenario Exception Handling • A rock blocks the view – Recover by taking the image from a different perspective (i.e. change the strategy) • The shadow cast by the rock fails the imaging code from identifying the objects in view – Reconfigure the imaging algorithm to work under these conditions 5/19/05 SelfMan 2005 13 5/19/05 SelfMan 2005 14 Method Regeneration: Method Regeneration: Exception Handling Exception Handling 5/19/05 SelfMan 2005 15 5/19/05 SelfMan 2005 16 Method Regeneration: Method Regeneration: Exception Handling Exception Handling 5/19/05 SelfMan 2005 17 5/19/05 SelfMan 2005 18 3

  4. Overall Architecture Planner Reconfigurable Vision for Plan Runner Models Robust Rover Mapping Deductive Controller Mode Mode Estimation Reconfiguration Plant 5/19/05 SelfMan 2005 19 Reconfigurable Vision Nominal Configuration Plant Model 5/19/05 SelfMan 2005 21 5/19/05 SelfMan 2005 22 Connection Contingent Configuration Command: Disconnect Inputs : x Connected Unconnected Outputs : x Command: Connect class Connection () { RawImage image_in; Models simplified for SegmentedImage image_out; clarity in this and following slides mode Connected (…) { primitive method disconnect () => Unconnected; } mode Unconnected (…) { primitive method connect () => Connected; } failure mode Failed (…) { … }; } 5/19/05 SelfMan 2005 23 5/19/05 SelfMan 2005 24 4

  5. SegmentColor Block Diagram TPN Macro RMPL Inputs : RawImage RMPL Library Compiler Outputs : SegmentedImage Usable TooDark TPN updates TPN CSP problem updates Kernel TPN data Initialize Mission TPN data CSP class SegmentColor () Algorithm Nexus Variables Temporal Consistency Check and Constraints { Domains Suite of Algorithms processed RawImage image_in; TPN Tell Consistency Check data FIFO SegmentedImage image_out; SSSP SDSP APSP Ask Consistency Check mode Usable ((image_in = Nominal)) { … } Common Data Location Consistency Check partial Dynamic solutions Repository mode TooDark ((image_in = Dark)) { … } CSP Solver Macro Expansion } plan updates Exception Handling Executive exceptions 5/19/05 SelfMan 2005 25 5/19/05 SelfMan 2005 26 Solution Analysis: Exception Solution Analysis: Exception Handling Handling Partial Solution 1. Execution begins… V 1 ={ } V 2 ={ } V 3 ={ } 1. Execution begins… 2. An error occurs, and an exception is thrown Ask Consistency Check Ask Consistency Check 2. An error occurs, and an exception is thrown V 4 ={ } V 5 ={ } V 8 ={ } 3. The exception-handling code is inserted Initial Variables Start End V I ={V 1 } EXCEPTION EXCEPTION Ask(B=x) Variables Tell(B=x) V 1 ={ } The delay represents delay handler V 2 ={ , } the amount of time spent in the original V 3 ={ , } Constraints process before the V 4 ={ , } Tell(B=y) Tell(A=x) � V 2 exception was V 5 ={ } � V 7 � V 3 thrown, plus an V 6 ={ } � V 8 upper-bound on � V 4 V 7 ={ , } � The handler is the TPN sub-process replanning time � V 5 Tell(A=y) corresponding to the RMPL “catch” statement V 8 ={ } � V 6 that matches the thrown exception 5/19/05 SelfMan 2005 27 5/19/05 SelfMan 2005 28 Solution Analysis: Exception Conclusions Handling Partial Solution 1. Execution begins… • Models of correct operation permits: V 1 ={ } V 2 ={ } V 3 ={ } 2. An error occurs, and an exception is thrown Ask Consistency Check 3. The exception-handling code is inserted V 4 ={ } V 5 ={ } V 8 ={ } – Detection and Diagnosis of failed components. 4. Replanning begins, pre-selecting anything that has already been executed Initial Variables – Reconfiguration of Software/Hardware Start End V I ={V 1 } EXCEPTION components to achieve high-level goals Ask(B=x) – Describe goals as abstract state trajectories. Variables Tell(B=x) V 1 ={ } • Software can be handled by adding: V 2 ={ , } V 3 ={ , } – Hierarchy to component organization Constraints Tell(B=y) V 4 ={ , } – Models of the environment � V 2 V 5 ={ } � V 7 � V 3 V 6 ={ } � V 8 � V 4 V 7 ={ , } � � V 5 V 8 ={ } � V 6 5/19/05 SelfMan 2005 29 5/19/05 SelfMan 2005 30 5

Recommend

More recommend