Self Healing Software Architecture

Published Date: 02 Nov 2017

Swapnil Saurav, Saptarshi Chakrobarty, Arun Gupta

Abstract

Self-healing is the name of the software system which deals with bugs. This system is meant for runtime issues. The introduction of Self Healing systems can change the present situation in software security. Traditional healing systems which can detect faults and correct them are wired into the system at code level whereas self healing system is dynamic. It is a new area of research which deals with fault tolerance for dynamic systems. Software, which is able to detect and react to faults is called self-healing software. These new systems can detect errors and acts on its own to correct it. Self-Healing system must know beforehand system’s expected behaviour in order to examine whether its actual behaviour deviates from its expected behaviour in relation of the environment. Most of the new techniques proposed for self healing system incur a significant amount of overheads which discourages their real time implementation. This paper describes about self-healing software application system and when should this system be applied. Using the rough set approach an attempt is made to determine when the self healing system be applied in case of faults.

Keywords

Self healing, dynamic, fault, fault tolerance, rough set

Introduction

Traditionally the research works in software engineering is based on simple assumption that system is created and modified offline. But these days systems are increasingly required to work continuously amid frequent change of resources and user requirements. Certain standard programming practices, such as capacitating extensive error handling capabilities through exception catching schemes, do contribute towards rendering systems fault-tolerant or self-adaptive,2 however, these methods are tightly coupled with software codes and are highly application-specific. Designs that enable software systems to heal themselves of system faults and to survive malicious attacks would radically improve the reliability and consistency of technology in the field. The endeavour to secure these benefits has originated the concept of self-healing systems. Self-healing can be defined as the property which enables a system to detect that it is not operating correctly and make the necessary adjustments to restore itself to normalcy by itself. Healing systems that require human intervention or intervention of an agent external to the system can be categorized as assisted-healing systems. The key focus or contrasting idea as compared to dependable3 systems is that a self-healing system should recover from the abnormal state and return to the normal state, and function as it was prior to disruption . A self-healing software system is a software architecture that enables the continuous and automatic monitoring, diagnosis, and remediation of software faults4

//The below paragraph needs a review

System-response includes the aspects of fault detection, degree of degradation, fault response and an attempt for recovery action or compensation for a fault. Fault detection approaches involved in a self-healing system include application system’s semantics-driven assertions [5, 6], supervisory checks, examining the computing answers, comparison of replicated components, online self-testing etc. System-completeness aspect deals with reality of knowledge limits, incompleteness in specifications and designs thereof. It also deals with the problem of system self-knowledge, system evolution etc.

This paper tries to mix the traditional methods of software reliability with the new self-healing techniques. Self-Healing techniques are good but they are also notorious for causing significant overheads during their self-diagnosis. So to save time and optimally utilize self-healing techniques another new technique rough sets is used at fault detection level to determine should a software fault be diagnosed by self-healing mechanism or by traditional methods to save time. The rough set will take data from the earlier diagnosis logs and form a set of rules according to which the system will determine how to fix the current fault.

Working Principle

The classic response to an attack is to terminate the attacked process or subsystem. This approach is considered safe but it is not good as it leaves the system exposed to similar attacks when the system is restarted and risk losing data. The new Self-healing techniques and mechanisms complement efforts to stop attacks from succeeding by new and innovative methods like using safe languages, libraries, transfer of control, etc. These methods defend the system proactively or at runtime. Some methods are exploiting signatures to prevent protected system from getting exposed to malicious input, compiling with stack integrity checking, using safe libraries. Self-healing mechanism keep a watch on system during runtime and response to attack in real time. The working of a self-healing software system can be broadly classified in four phases depicted in the figure.

Self –Healing software Architecture

Following identification, the system will need to create one or more possible fixes tailored to the particular instance of the fault. The nature of these fixes depends on types of faults and the available protection mechanisms. Potential fixes to software faults include snapshot rollback, input filtering, increased monitoring or isolation for the vulnerable process, selective application of any runtime protection mechanism, and others.

Each candidate fix produced by the system may then be tested to verify its efficacy and impact on the application. This testing can take several forms, including running pre-defined test-suites, replaying previously seen traffic (including the input that triggered the fault), etc. If an acceptable fix is produced, the system is updated accordingly. This can be done through established patch-management and configuration-management mechanisms, or any other suitable mechanism.

Note that different fixes, or fixes of different accuracy/performance levels, may be successively applied as the system spends more time analysing a fault. For example, the initial reaction to a failure may be a firewall reconfiguration. After further analysis, the system may produce a software patch or a content filter that blocks the specific input that caused the fault. Finally, the system may then replace the specific content filter with a generalized signature, obtained through signature generalization [7], dynamic analysis of the targeted software [8], or other means.

Self-Healing Strategies

2.1 Classification of software faults

The first step toward self-healing is the automatic recognition of software failures. The IEEE standard 1044 [9] documents a comprehensive list of categories and classifications for software anomalies. The taxonomies of software failures, errors, and faults have been discussed extensively for many different types of software systems. Commonly accepted definitions are as follows. A software fault refers to a defect in a system. An error is a discrepancy between the observed behaviour of a system and its specified behaviour. A software failure occurs when the delivered service deviates from correct service, a departure of system behaviour from user requirements. A software fault or error may not necessarily cause a software failure [10].

The following are the major categories of software faults discussed in the literature for various types of software systems [11] [12]:

Syntactic faults: interface faults and parameter faults

Semantic faults: inconsistent behaviour and incorrect results

Service faults: QoS faults, SLA related faults, and real-time violations

Communication / interaction faults: time out and service unavailable

Exceptions: I/O related exceptions and security-related exceptions

A syntactic fault occurs when the structures of messages or parameters of a requester do not agree with those of a provider. While compilers are able to capture these types of faults in a single program, they can happen in component- based software and web services where a requester and a provider may be constructed independently of each other. Semantic faults, on the other hand, represent inconsistencies between the original design and the programmers' intention. Semantic faults are more challenging to diagnose and often require specialized instrumentation to detect them. A service fault occurs when the performance of the delivered service deviates from the required service performance as specified in the Quality of Service (QoS) or Service Level Agreement (SLA). These types of faults cause degraded performance of the system. Faults also occur due to communication and interaction among components, services, and subsystems in both distributed and centralized systems. The absence and unresponsiveness of providers and the timing of service requests are examples of communication and interaction faults.

Unhandled exceptions are another source of software faults that often lead to the abnormal termination of applications. Exception frameworks defined in languages, such as Java and C++, provide both built-in and user-defined exceptions. However, they do not provide a mechanism to prevent unexpected application termination due to unhandled exceptions. The different levels of granularity. A Modelling Framework for Self-Healing Software Systems in the exception framework facilitate the specification of exception handling to recover from specific and general software faults.

2.2 Fault detection

The detection methods for different software faults vary depending on the types of faults. For syntactic faults, the structures of messages or parameters are verified against design requirements and failures to conform to design requirements will result in syntactic faults. Communication and interaction faults may be detected by the involved entities. For instance, wrappers can be added to web service invocation to detect the availability and responsiveness of service providers. For faults related to exceptions, the exception framework defined in programming languages provides a uniform approach to fault detection. C++ and Java, for example, provide the "try - catch" constructs to capture both specific and general programming exceptions. The framework can be extended to capture user-defined exceptions as well.

Service faults require the monitoring of services to determine whether the provided services meet the required QoS or SLA agreement. Different types of service faults may require different detection mechanisms. For instance, if the invocation of a service must be completed within a specific time frame, the invocation can be timed such that the failure to respond within the required time frame is detected. The detection of semantic faults is more challenging. It requires specialized instrumentation and / or domain-specific knowledge to understand the correct vs. incorrect behaviour of a component, service, or system.

Various generic approaches can also be applied to fault detection. One of the common approaches is to perform source code instrumentation. Extra code is inserted into the source code to facilitate the detection of software anomalies. Aspect-oriented programming (AOP) [13], for instance, can be applied to attach additional functions to the system for the purpose of detecting system performance and faults. Sensors and event collection and processing can also be applied to detect software faults. Majority voting [14], for instance, can be found in telecommunication systems to detect software or system anomaly to ensure high reliability and availability.

Failure prediction can also be used to enhance the above detection methods. This involves both learning and reasoning about failures. Preventative and corrective actions can be taken before faults occur to avoid the loss of functionality or disruption of services [11].

2.3 Fault resolution and self-healing

Various approaches have been described to handle software faults: fault prevention, fault removal, and fault tolerance. Fault prevention and removal aim to achieve fault-free software through robust design and rigorous testing. The goal of fault tolerance is to ensure the continual operation of a system in the presence of faults.

3. Use Of Rough Set to determine application of self-healing software

Using of self-healing techniques like ASSURE, Vigilante, DIRA, TLS, Error Virtualization are effective but they incur significant overheads which prevent their practical use. To overcome this we have proposed using of rough set technique after fault detection to determine whether that fault should be solved using self-healing techniques or the traditional methods of fault recovery and mitigation.

Let, T = (U, A) and let and, then we can approximate X by using the information contained in B by building the lower and upper approximations of X, represented as and respectively, where, is known as the lower boundary region of the attribute set w.r.t decision values and , is known as the upper boundary region of the attribute set w.r.t decision values.

The accuracy of the approximation is given by,

If then X is a crisp set or if X is a rough set.

In classical rough set theory the boundary region B of X is given by, consists of those objects that we cannot decisively classify in B. A set is called rough if its boundary region is non-empty, otherwise the set is crisp. If we assume, c is dispensable in T, if, otherwise attribute c is indispensable in T. A subset c of the attributes set C is a reduct of C with respect to decision attribute (D) if and only if the following conditions are satisfied.

Lower-boundary of [c]/[D] =Lower-boundary of [C]/[D]

, Lower-boundary of Lower-boundary of

And the core attribute is decided from the intersection of all the reducts.

Algorithmic(a1)

Documentation

(a2)

Computation

(a3)

Hardware

(a4)

Buffer

Contention

(a5)

Deadlock Threads

(a6)

Read / Write Contention

(a7)

Source

Code Bugs

(a8)

Decision

(a9)

1

0

0

0

0

0

0

0

0

1

0

1

0

0

0

0

0

0

1

1

1

0

0

0

0

0

0

1

0

0

1

0

0

0

0

1

1

1

0

0

0

0

1

0

1

1

0

0

0

0

0

0

1

1

1

1

1

1

1

0

0

0

1

1

0

0

1

0

0

0

0

0

1

0

0

0

0

0

0

1

0

0

1

0

0

0

1

1

1

1

0

0

1

1

0

1

1

0

1

1

1

0

0

1

1

1

0

1

1

0

1

0

1

0

1

1

1

1

1

1

1

0

1

0

1

1

0

0

0

1

1

1

1

0

1

0

1

0

0

1

1

1

1

1

0

0

0

1

0

0

0

1

1

0

0

0

1

0

0

0

1

0

1

1

1

1

0

0

0

1

1

1

1

1

1

0

0

0

1

0

1

1

1

1

1

1

1

1

1

We have applied the rough set approach in the above dataset to detect whether self-healing of the software system is essential or not.

Calculations

Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/[D]={ 1,2,3,5,7,10,11,12,13,14,15,16,21}

Upper-boundary of [a1,a2,a3,a4,a5,a6,a7, a8] / [D] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17, 18,19,20,21}

Boundary – region is= {4, 6, 8, 9, 17, 18, 19, 20}

The reducts are [a2, a3, a4, a6, a8], [a2, a4, a6, a7, a8], [a3, a4, a6, a7, a8], [a4, a5, a6, a7, a8], because

Lower-boundary of [a2]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a3]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a4]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a5]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a6]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a7]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a8]/ [D] Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a2, a3, a4, a6, a8]/[D]= { 1,2,3,5,7,10,11,12,13,14,15,16,21} = Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a2, a4, a6, a7, a8]/[D]= { 1,2,3,5,7,10,11,12,13,14,15,16,21} = Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a3, a4, a6, a7, a8]/[D]= { 1,2,3,5,7,10,11,12,13,14,15,16,21} = Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

Lower-boundary of [a4, a5, a6, a7, a8]/[D]= { 1,2,3,5,7,10,11,12,13,14,15,16,21} = Lower-boundary of [a1, a2, a3, a4, a5, a6, a7, a8]/ [D]

From the set of all the reducts, the core attributes are [a4, a6, a8].

If (a4 = 0 & a6 = 0 & a8 = 0) => (a9 = {0 [3], 1[1]})

If (a4 = 1 & a6 = 0 & a8 = 0) => (a9 = {0 [1], 1[2]})

If (a4 = 0 & a6 = 0 & a8 = 1) => (a9 = {0 [1], 1[2]})

If (a4 = 0 & a6 = 1 & a8 = 1) => (a9 = {1[2]})

If (a4 = 1 & a6 = 1 & a8 = 0) => (a9 = {1[2]})

If (a4 = 0 & a6 = 1 & a8 = 0) => (a9 = {1[1]})

If (a4 = 0 & a6 = 0 & a8 = 1) => (a9 = {0 [2], 1[2]})

If (a4 = 1 & a6 = 1 & a8 = 0) => (a9 = {1[2]})