Model-based Adaptation for Self-Healing Systems David Garlan, Bradley Schmert ELSEVIER Sciences of Computer Programming 57 (2005) 27-44 이경렬 {flexagon@skku.edu} Software Engineering Laboratory Sungkyunkwan University

Contents 1. Introduction 2. Overview of the approach 3. Implementation 4. Experience 5. Conclusions and future work

Necessity of Self-Healing Introduction Necessity of Self-Healing Increasingly systems are required to work continuously System resources may change frequently Software engineers will need cost-effective techniques and mechanisms Self-adaptation have been around for a long time Language : exceptions and run-time assertion checking Algorithm : network protocols, self-stabilizing algorithms → but, systems are tightly integrated in code level However, they suffer from the problem Cannot determine the true source of the problem Cannot recognize “softer” system anomalies

Advantage of this approach Introduction Alternative approach “externalize” adaptation determining when a system’s behavior is within the envelope of acceptable system parameters when it falls outside of those limits, adapting the system. Advantage of this approach Different models can be chosen Externalized mechanisms can support reuse They can be easily changed They can exploit a large body of existing work on analytical methods for improving attributes such as performance, reliability, or security

Challenging research problems Monitoring How to add monitoring capabilities in non-intrusive ways. What kinds of things can we monitor. How to build reusable monitoring mechanisms easily. How to design components and systems so that they can be more easily monitored? Interpretation How to make sense of low-level monitored Information. How to determine when there is problem. How can we pinpoint the source of a problem. What models are best paired with specific system.

Challenging research problems Resolution How to repair a system How to select the best repair action from possible repairs Can we guarantee that repairs will actually improve things How to reconcile conflicting repairs obtained multiple models Can we improve a system when no specific error has arisen Adaption How to cause the adaptation to occur in a running system How should we design/build software systems and components What do we do if something goes wrong

Challenging research problems General open issues Overheads associated with monitoring, interpretation, resolution and adaptation. what kinds of problems and behaviors are best suited. How to minimize the costs of making systems self-adaptive. Does the approach scale to Internet-based systems and services.

Overview of the approach

Overview of the approach

Self-healing mechanism

Self-healing mechanism Detection A11:[Failed] Notify Component Self-Healing Controller Component Monitor A3 : Input Placed A5 : Read Input A6 : Input Info Read A2 : Input arrived A9 : Message Arrived A10 : Message Placed A1 : Input External Object <Connector> Connector 1 A4 : Read Input A7 : Input Info A8 : Message <Task> Task 1 <Connector> Connector 2

Self-healing mechanism Reconfiguration before repair The reconfiguration isolates the sick object from healthy objects at runtime Notify the sick symptom of the object to the other components block objects related to the repair and testing A12 : Request Reconf. Plan A16 : Component Failure Notification Component Reconfiguration Plan Generator Component Self-healing Controller A13 : Reconf. Plan A14 : Reconf. Plan A15 : Com. Failure A17 : Failure Notification Component Reconfiguration Executor <Connector> Connector 1

Self-healing mechanism Repairing and testing A33 : Request Result Component Self-healing Controller A37 : Repair Finished A18 : Request Repair Plan A20 : Repair Plan A19 : Repair Plan Component Repair Plan Generator A34 : Test Result Component Monitor Component Repair Executor A22 : Test Begin A35 : Test Finished A24 : Input Arrived A25 : Input Placed A21 : Initialize A27 : Read Input A28 : Input Info Read A23 : Test data A31 : Message Arrived A32 : Message Placed <Connector> Connector 1 A36 : Initialize A29 : Input Info A26 : Read Input A30 : Message <Task> Task 1 <Connector> Connector 2

Self-healing mechanism Reconfiguration after repairing A38 : Request Reconf. Plan A42 : Component Health Notification Component Reconfiguration Plan Generator Component Self-healing Controller A39 : Reconf. Plan A40 : Reconf. Plan A41 : Com. Health A43 : Component Health Notification Component Reconfiguration Executor <Connector> Connector 1

Self-healing elevator system

Self-healing elevator system

Self-healing elevator system

Self-healing elevator system

Conclusion In this paper Design of self-healing components Describe the self-healing mechanism