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

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

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

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

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

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

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

8. Overview of the approach

9. Overview of the approach

10. Self-healing mechanism

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

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

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

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

15. Self-healing elevator system

16. Self-healing elevator system

17. Self-healing elevator system

18. Self-healing elevator system

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