15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems
A Case Study: A Model-Based Approach to Retrofit a Network Fault
Management System with Self-Healing Functionality
Yan Liu Jing Zhang Michael Jiang David Raymer
Motorola Labs, Motorola Inc.
Schaumburg, IL 60133, USA
{yanliu, j.zhang, michael.jiang, david.raymer, john.strassner}@motorola.com
Abstract
Adding self-healing capabilities to network management
systems holds great promise for delivering important goals,
such as QoS, while simultaneously lowering capital expen-
diture, operation cost, and maintenance cost. In this pa-
per, we present a model-based approach to add self-healing
capabilities to a fault management system for cellular net-
works. We propose a generic modeling framework to cate-
gorize software failures and specify their dispositions at the
model level for the target system. This facilitates the deploy-
ment of a control loop for adding autonomic capabilities
into the system architecture, which include self-monitoring,
self-healing, and self-adjusting functionality. While self-
monitoring oversees the environmental conditions and sys-
tem behavior, self-healing is accomplished by instrument-
ing the system with self-adjusting operations. We include a
case study on a prototype Intelligent Network Fault Man-
agement system to illustrate this approach by showing how
these autonomic capabilities can be added and deployed.
Specifically, these autonomic capabilities are derived from
self-* model specifications, and are used to mitigate the risk
of specified failures and maintain the health of the system in
response to different types of faults encountered.
1 Introduction
The highly competitive nature of the telecommunica-
tions industry demands an extremely high-level of system
availability, reliability, and survivability for network man-
agement systems. The presence of a large variety of ser-
vices, each with their own needs and interactions, further
exacerbates the design and performance of network man-
agement systems. Fault management is considered one of
the most crucial features for reliable and efficient network
performance. As a network fault management system in-
volves extensive data processing and troubleshooting un-
978-0-7695-3141-0/08 $25.00 © 2008 IEEE 9
DOI 10.1109/ECBS.2008.30
John Strassner
der real-time constraints, care must be taken to avoid re-
source exhaustion. However, events such as alarm storms
and unexpected transient network faults caused by unfore-
seen events result in sudden loss of functionality, perfor-
mance degradation, and sometimes even the failure of the
entire system under extreme conditions. Hence, the ability
of a network fault management system to capture software
failures effectively, react to them rapidly, and recover el-
egantly when failures occur, is critical to assuring highly
dependable network system performance.
As an emerging discipline, the purpose of autonomic
computing is to manage complexity. By transferring more
manual functions to involuntary control, additional re-
sources are made available to manage higher-level pro-
cesses. The fundamental management element of an au-
tonomic computing architecture is a control loop. Figure 1
illustrates the concept. The idea is to instrument a Man-
aged Resource so that an Autonomic Manager can com-
municate with it. This is done using sensors that retrieve
data, which is then analyzed to determine if any correc-
tion to the managed resource(s) being monitored is needed
(e.g., to correct “non-optimal”, “failed” or “error” states). If
so, then those corrections are planned, and appropriate ac-
tions are executed using effectors that translate commands
back to a form that the managed resource(s) can under-
stand. This usually results in the reconfiguration of that
managed resource, though it can cause the reconfiguration
of other managed resources that are affecting the state of the
managed resource that is being monitored. The Autonomic
Computing Element embodies the control loop, and enables
the autonomic manager to communicate with other types of
autonomic and non-autonomic managers using its sensors
and effectors.
Autonomic computing and networking are both char-
acterized by the set of capabilities often represented by
the phrase self-*; which include self-protection, self-
configuration, self-healing, and self-optimization, all aim-
ing to reduce the business, system, and operational com-
plexity of a system [1, 2]. From a system perspective, an

Figure 1. An Autonomic Computing Ele-
ment(ACE)
autonomic computing system is an adaptive system, which
reacts to changes in user needs, business goals, environmen-
tal conditions, and system functionality, and automatically
adapts its functionality to meet new demands on its func-
tionality while protecting business goals. Self-awareness is
necessary for supporting the adaptive behavior of complex
systems. This notion of behavior includes expected behav-
ior, in terms of the correct, safe, and expected operation of
the system as well as unexpected deviations from such be-
havior. Self-healing capabilities provide rapid recovery and
recuperation against system failures to support survivability
and enhance reliability in real-time system operation.
In this paper, we propose a model-based approach for
adding selected autonomic capabilities, which adds self-
healing functionality, into the critical components of a net-
work fault management system that have a significant im-
pact on system dependability. Self-monitoring oversees
the current environmental conditions and system behavior,
building a baseline to add self-awareness capabilities. It is
responsible for monitoring the system states and environ-
mental conditions, analyzing these states and the changes,
and thus identifying and detecting system failures. Once a
failure is detected and identified, self-healing operations are
enabled for dynamically responding to the identified failure
to either fix the failure or mitigate it in some way. These
actions are usually accomplished by self-adjusting the cor-
responding system configurations and operations. Together,
all self-* approaches complete an adaptive self-healing
framework and offer a sound solution towards achieving
high system assurance.
Furthering our previous case study [3], a modeling
framework is facilitated to retrofit a prototype network fault
management system, called the Intelligent Network Fault
10
Management(INFM) system, by specifying and implement-
ing the self-healing capabilities to correct the software fail-
ures. UML models are first extracted from the critical com-
ponents of the software system. Then, model constructs are
used to classify software failures, specify the dispositions
of such failures apart from the models that capture the base
functionality of the system, and define the healing actions
to be taken in the form of self-adjusting operations. The
intended self-healing functionality is thus achieved by inte-
grating the base code with the needed self-* functionality
instrumented with run-time failure detections and mitiga-
tion strategies that are derived from the self-* model speci-
fications.
The paper is organized as follows. Section 2 describes
the background of the targeted system and the proposed
architectural alteration for adding autonomic capabilities.
Section 3 presents the proposed framework for facilitat-
ing model-driven autonomic computing for failure miti-
gation. Section 4 presents the application of the model-
based approach to deploying the autonomic control loop
within INFM and implementing the self-monitoring, self-
healing, and self-adjusting functionality using the model-
driven framework. Section 5 summarizes related work, and
Section 6 concludes the paper and describes some future
work.
2 Adding Self-Healing Functionality to
INFM
To illustrate our approach, a network fault management
system for a real world telecommunication network is stud-
ied. In this section, we introduce the targeted system and
describe the architectural alteration needed for supporting
the autonomic capabilities needed for self-healing.
2.1 Background
We study the fault management framework of a CDMA
cellular network management system, namely the Inte-
grated Network Management System (INMS). The main
components of the INMS provide an integrated solution
to the core network management working objectives, i.e.,
FCAPS (fault-management, configuration, accounting, per-
formance, and security). Alarm correlation is the most im-
portant feature of the fault management system. On a daily
basis, an operation console can receive more than 100,000
network alarms, all of which are processed by the fault man-
agement module. The functionalities provided by the alarm
correlation feature consist of 1) filtering out the informa-
tional alarms, such as ”Cleared” and ”Warning” types of
alarms; 2) reporting meaningful alarms that are regarded as
actionable or as requiring operator attention; and 3) provid-
ing assistance in troubleshooting. Network operators rely
on the alarm correlation feature to reduce the number of
alarms to a limited number that could be handled within the
required time constraints. The significant reduction, usually
greater than 80% on average, is achieved by correlating the
alarms using alarm patterns and hidden correlations discov-
ered by machine learning algorithms.
Figure 2. Adding self-healing functionality to
the Intelligent Network Fault Management ar-
chitecture
Figure 2 shows the architecture of the INFM component
that carries out the alarm correlation using frequent pattern
discovery algorithms. By design, there exist two types of
correlation algorithms, on-line and off-line for real-time and
after-hours correlation operations, respectively. The on-line
algorithm is employed during real-time operation to corre-
late the incoming alarm streams using a sliding time win-
dow, usually by minutes. It is used to find transient patterns
as well as time and domain specific correlations among spe-
cific alarms. The off-line algorithm runs on a much larger
set of alarms that have been recorded during a certain period
of time, usually in days, and discovers the common patterns
and correlations among certain types of alarms. Both pat-
tern discovery algorithms are parameterized by minimum
support and minimum confidence. Minimum support is the
minimum value in terms of frequency a pattern must ex-
ceed to be calculated while mining from the learning data.
With the pattern in the common form of A ⇒ B, a con-
fidence value is defined as the percentage of instances in
the learning data containing B in addition to A with regard
to the overall number of instances containing A in the data
set. The minimum confidence value is hence used to de-
fine the minimum value of confidence a pattern must ex-
ceed to be calculated. Usually, both parameters are set on
a scale of 0..1 and are used to control how candidate pat-
terns are constructed. The analysis provides their frequency
of occurrence as well as a confidence factor in the discov-
ered patterns [4, 5]. When the number of instances is fairly
11
large, the time complexity of the algorithm increases dra-
matically, although the value of the minimum support only
decreases by a small magnitude. For the on-line algorithm,
this causes a violation of real-time constraints and fails to
provide prompt correlation operation. For the off-line al-
gorithm, the large volume of alarms would likely cause re-
source exhaustion or crash of the algorithm. This motivates
us to add autonomic capabilities to resolve such failures and
maintain the healthy state of the fault management system.
2.2 Adding Autonomic Capabilities
Inspired by adaptive control schemes, we add an au-
tonomic control loop to the architecture to support self-
healing functionality, taking the form of “monitor” and
“control” as shown in Figure 2. Inside this loop, the self-
monitoring activities collect information from the system
on algorithm executions and check against its pre-defined
failure conditions. When a failure is detected and identi-
fied, a signal is sent to the autonomic controller to deter-
mine the proper healing action. The autonomic controller
takes control and directs the necessary actions to be taken
on the algorithms. The proposed self-healing mechanisms
are mainly different forms of rejuvenation, which is com-
posed of shutting down the current correlation process prop-
erly, adjusting the parameters and configuring the algorithm
input if necessary, and restarting the execution of the algo-
rithm. As long as the targeted system is well modularized
and maintains an architectural consistency, recent studies in
modeling profiles and fault tolerance using UML [6, 7] sug-
gest that the adaptive framework could be realized with the
assistance of modeling techniques. More specifically, for a
legacy fault management system, we propose a three-step
approach as follows:
1. Identify the critical features and extract UML models
from the legacy code for these features;
2. By extending the UML specifications and capabili-
ties with profiles and domain-specific modeling con-
structs, model the self-monitoring, self-healing, and
self-adjusting aspects for these models and validate the
integrated models;
3. Generate the code for these autonomic aspects and in-
sert it into the legacy code.
All three steps can be either automated or semi-automated
with tool support. These three steps are explained in detail
in deeper sections.
3 Modeling Self-* Capabilities
We propose a generic modeling framework to facilitate
the integration of self-* capabilities with legacy software
systems. The aim of this framework is to define failures
from high-level model specifications in order to provide a
unified platform to integrate various existing self-healing
techniques (failure mitigation strategies in particular), as
well as to add self-* capabilities to existing software sys-
tems.
3.1 Failure Specification and Modeling
Figure 3 shows a general model representation for soft-
ware failures and self-healing mechanisms. Different types
of failures may be present for a software, which is modeled
as either an atomic software component or a composite of
software component(s) [8]. A software failure can be de-
tected by one or more different types of detectors; failures
are then analyzed by one or more failure analyzers. More
than one failure might be analyzed by an analyzer to dis-
cover the relationships among these failures and help bet-
ter characterize these failures and their underlying causes.
A failure analyzer also predicts and/or determines the risk
raised by the failure(s). In accordance with the different ex-
tents of damage that a failure might bring to the system, the
mitigator invokes different failure mediation strategies and
takes different sets of actions that transform the software
from its failure state to a specified operational state [9].
Figure 3. The model of failure, risk, and miti-
gation
A number of software failure classifications are defined
in reliability engineering literature. Some of them simply
classify failures into different types based on their risk lev-
els, while others focus on the causes of the failures. In our
proposed self-healing framework for failure detection and
mitigation, we need a classification that can be used to ef-
fectively categorize the failures while stressing the domain
specific constraints and operation critical requirements that
a failure impacts. This is consistent with Pumfrey’s clas-
12
sification of failures [10], which considers the component
or system as the provider of a service or a set of services,
each consisting of a particular type of value delivered within
a defined interval. The model shown in Figure 3 specifies
Pumfrey’s categories of software failures that may occur:
provision failures, timing failures, and value failures.
• Provision Failure. Both omission failures and commis-
sion failures are considered provision failures, as the
former indicates no service is delivered while the lat-
ter delivers services that are not required.
• Timing Failure. This includes late or early delivery
of service. The timing failure is usually associated
with certain time constraints, which can be a real time
constraint or a relative deadline with respect to cer-
tain events. For example, a time limit can be imposed
on the alarm correlation process in a fault manage-
ment system, as opposed to the relative deadline which
states that “the alarm correlation must be completed
before the next batch of alarms are received”.
• Value Failure. This type of failure is defined by the
incorrect value provided by the service.
Each type of failure requires its specific failure detec-
tors. The effects of such failures can be divided into three
categories based on their risk index assigned by the ana-
lyzer: insignificant, moderate, and significant. Although
most methods proposed and used for failure risk analyses
are mainly analytical, thresholds and criteria for such di-
visions are very domain specific and usually obtained em-
pirically.This implied that certain adaptive behavior includ-
ing learning and reasoning is needed to support the deci-
sion making. Similarly, the invocation of failure mitigation
strategies also requires adaptivity. In the proposed model,
based on the notion of self-healing, we divide the existing
mitigation strategies into three categories: report, rejuve-
nate, and recover.
• Report. When the risk of a failure is considered in-
significant (i.e., it will not affect the normal operations
of the system), it is only required that such a failure be
reported and recorded. No immediate action is neces-
sary in this case.
• Rejuvenate. Software rejuvenation, defined by Huang
et. al. [11], is basically resolving the failure by el-
egantly stopping the current operation and restarting
the application. This strategy usually is more powerful
when a failure is highly likely or present that is haz-
ardous yet not fatal to the system operation. Predictive
models are thus particularly useful for rejuvenation ac-
tions.
 • Recover. Recovery is needed after a failure occurs.
This usually includes failure quarantine/masking, con-
sequence/risk mitigation, and removal of the causal
faults.

3.2 Modeling and Deploying Self-*

Figure 4 shows the flow chart for implementing the pro-

posed model-based approach. A self-* model is described
as a set of constructs that are instantiated and integrated
with the base system models. For many legacy systems
whose models are unavailable, the base model can be ex-
tracted from the code. It should be noted that the self-
healing feature is kept separate from the base functional-
ity of the target software system. This decomposition of
the base functionality and the self-healing feature improves
modularity and re-usability of the self-* modules. The main
advantage of this approach is that it allows developing and
maintaining the self-* models independently from the base
model. Furthermore, many of these self-* models can be ap-
plied to all levels in the software system hierarchy through
model composition.
Integrating and deploying a self-* model to the base
application model is done by model composition tech-
niques. Typically, model composition involves merging two
or more models to obtain a single integrated model. Aspect-
Oriented Modeling (AOM)[12] is one of the promising
means to support model composition. Self-* functionalities
can be specified in separate aspect modules, which can be
instantiated and bound to the base models via a specialized
aspect weaver.
It is thus suggested that the self-* models be specified
in a platform-independent manner. For instance, to sup-
port a complete self-healing application, a family of code
generators need to be employed for transforming platform-
independent models into platform-specific code, each defin-
ing how the self-healing features are implemented on a dif-
ferent platform. As shown in Figure 4, the self-* model
can be translated into platform-specific implementations by
a code generator or by manual development (when cer-
tain features are beyond model-driven software capabili-
ties). Specifically, the representation of failures and their
responding resolutions are transformed into low-level im-
plementations that detect the failures and take the appropri-
ate actions to restore the system to the specified operational
state. The base code is then augmented with the self-healing
instrumentation by integrating both code bases. As a result,
autonomic capabilities are added to the legacy software sys-
tem by first constructing the self-* models, followed by di-
rectly mapping the self-* aspects to the representation of the
composed self-healing enabled software model, upon which
model-based analysis can be performed for system verifica-
tion and validation.
Figure 4. Adding self-* capabilities: a flow
chart
4 Modeling and Deploying Self-Healing for
INFM
Following the modeling approach, we first specify the
failures and their corresponding resolutions. Then, with the
help of reverse modeling tools, we extract the UML models
from the existing source code of INFM. After that, we add
the self-healing aspects into the base models and complete
the new implementation of the monitor and control loop.
The code used to implement the self-monitoring function-
ality is automatically generated using model driven archi-
tecture (MDA)-like techniques. The self-healing code for
failure mitigation, on the other hand, is manually developed
and integrated with the base code. The following subsec-
tions explain this process in detail.
4.1 Failures and Resolution
The performance of alarm correlation algorithms is very
sensitive to the settings of both parameters of the pattern
discovery algorithms, namely the minimum support value
and the minimum confidence value, denoted by supp and
conf in the rest of the paper. Table 1 lists the run-time
failures that have occurred during operations that were not
covered in the original system design, the possible causes of
these failures, and the intended resolutions for the failures.
These three major failure conditions listed in the table are
considered dependability critical because:
• it is imperative not to violate the real time constraints
on operations for the online correlation algorithm as
well as to avoid the possible operational problems

13
 Table 1. INFM Software Failures and Resolution Table for Alarm Correlation
Failure Possible Causes Resolution
Timeout supp set too low Increase supp and re-run
1) Increase conf and recheck patterns;
Too many(> U ) patterns returned supp or conf set too low if too many(> U ) patterns returned;
2) increase supp and re-run.
1) Decrease conf and recheck patterns;
Too few(< L) patterns returned supp or conf set too high if too few(< L) patterns returned,
2) decrease supp and re-run.

caused by resource exhaustion for the off-line corre-

lation algorithm.

• relatively small values of supp and conf might cause

the algorithms to return a large number of patterns.
Although small values of both parameters would pro-
vide a more comprehensive list of candidate patterns,
it raises issues in handling the large quantity of pat-
terns. Furthermore, low supp and conf values in-
crease the likelihood of applying false positive patterns
to the succeeding correlation procedures.

• relatively large value of supp and conf , on the other

hand, might cause the algorithms to return too few pat-
terns. This can negate the effectiveness of the correla-
tion algorithms and increase the false negative ratio in
pattern validation.

Based on the failure classification in Section 3, the time-
out failure can be classified as a typical timing failure and
is considered critical for on-line execution. Since it is less
hazardous for off-line alarm correlation, the allowed times
for re-run could be adjusted to a larger number. Similarly,
too few patterns and too many patterns might have differ-
ent risks under different operational modes. The adjust-
ment of parameters in both situations needs further analy-
sis, whereby a failure analyzer is required to carry out the
predictive reasoning based on current environmental con-
ditions and constraints as well as the history performance
of the algorithms. In other words, the failure analyzer is
indeed an adaptive component that fine tunes the behavior
and strategy of the self-healing actions.
4.2 Modeling Timeout Failure Manage-
ment Aspect
Figure 5 shows an aspect model for managing timeout
failure. The reserved keyword proceed refers to a certain
operation (e.g., the alarm correlation algorithm in the INFM
case study) that has sensitive timing concerns and needs to
Figure 5. Timeout failure management aspect
model
be analyzed upon the timeout failure. The aspect model
intercepts and wraps this operation with a sequence of fail-
ure management activities. The aspect process first initiates
the counter for the allowed number of re-run times. If the
counter already exceeds the allowed number of times for re-
run, it means that the failure cannot be resolved and has to
be reported. The whole application thus must be aborted.
Otherwise, the process will start a timer with a value T,
in sync with the execution of the proceed operation. The
proceed operation and the timer are surrounded by an in-
terruptible activity region (denoted as a dashed rectangle
with rounded corners), representing that whenever the flow
leaves the region via interrupting edges, all of the activities
in the region will be terminated. Specifically, if the proceed
operation completes execution successfully before time out,
the control of the flow will return to the base process (via
a bull’s eye symbol) and continue the next activity that fol-
lows the proceed operation. Otherwise, the proceed pro-

14
cess will be shut down properly and a timeout failure will be
captured and passed to the failure analyzer/mitigator, which
is responsible for determining the failure risk and calculat-
ing the corresponding mitigation strategies for reconfigur-
ing algorithm parameters. The control loop is thus realized
by re-running the algorithm with the new parameter values.
4.3 Modeling Pattern Failure Manage-
ment Aspect
Similarly, the pattern failure management aspect is mod-
eled as in Figure 6. In contrast to the timeout failure, the
pattern failure is identified by a special component after the
proceed algorithm is completed. If a failure is detected,
RecheckP atterns will filter the returned patterns by ad-
justing the value of conf . If the failure still exists, the con-
trol of the flow will be passed to the pattern failure ana-
lyzer/mitigator, which will adjust the algorithm parameters
based on the reasoning of different failure types, as shown
in Figure 7.
Figure 6. Pattern failure management aspect
model
4.4 Applying Autonomic Aspects on Ex-
tracted Base Models
The autonomic aspects (e.g., timeout and pattern failure
management) are applied to the base models of INFM that
15
Figure 7. Pattern failure analyzer/mitigator
model
are extracted from the source code with the aid of UML
reverse engineering tools. Figure 8 illustrates a fragment
of the extracted UML activity diagram, which models the
flow of the alarm correlation process logic in INFM. The
control flow starts with database connection, followed by
the initiation of the parameters (i.e., supp and conf ) for
the pattern discovery algorithm. After the algorithm exe-
cution is completed, a special operation will be performed
to process the patterns that are generated. The timeout and
pattern failure management aspect models are attached to
the ExecuteAlgo operation with particular parameter val-
ues specified. The base models and the autonomic aspect
models are then integrated through an underlying aspect-
modeling weaver, as shown in Figure 9. The proceed oper-
ation is replaced by the ExecuteAlgo operation. The initial
and return symbol of the aspect models are connected to the
pre- and post- flow of the ExecuteAlgo, respectively.
Figure 8. Applying failure management as-
pects to the extracted base models of alarm
correlation process in INFM
4.5 Code Generation from the Integrated
Models
We apply Aspect-Oriented Programming (AOP)[13]
technique to support source code integration. AOP is an
effective way that enables code instrumentation by encap-
sulating additional (mostly crosscutting) functionalities in
a self-contained aspect module. In AOP terminology, an

Figure 9. Integrating autonomic behavior
with INFM alarm correlation base model
aspect is composed of pointcuts and advice. P ointcuts
denote a set of specific points in the control flow of the sys-
tem, and advice contains the code that are going to be wo-
ven into the source base. The aspect and the base modules
are integrated by an underlying aspect weaver.
The autonomic aspect models are translated into an as-
pect by a specialized self-* code generator. The pointcut
in this case is the operation ExecuteAlgo. The autonomic
behavior is captured in advice. The base code for alarm
correlation process is then augmented with the self-* in-
strumentation via an aspect weaver. (In this particular case
study, we choose AspectJ[14] as the underlying weaver, be-
cause INFM is implemented in Java and AspectJ is consid-
ered as the most popular and mature aspect weaver in the
market.) As a result, a self-healing enabled INFM system is
constructed from the high-level model specifications.
4.6 Discussion
One of the ultimate goals of software engineering is to
construct software that is easily modified and extended.
Retrofitting legacy software systems is never an easy task
as it usually involves extensive rework over the legacy code.
A desired solution is to leverage the benefits of modulariza-
tion such that a change in a design decision such as adding
16
well-defined self-healing functionality is centralized to one
particular location. By adopting the aspect-oriented ap-
proach to specifying self-healing activities, the aspect mod-
els can be defined independently from the base functional-
ity. Such kind of separation of concerns greatly improves
the reusability, changeability, and maintainability of the
system. Our experience has led us to believe that modeling
based retrofitting is a promising approach to support adding
self-healing functionality to legacy softwares in a more ef-
ficient and effective way based on modularization. In the
meantime, our study also shows that a moderate amount of
effort has to be put onto the model extraction and verifica-
tion process. In general, the required effort increases when
the level of modularization of the legacy code decreases.
5 Related Work
In the arena of fault tolerant computing, there are a num-
ber of approaches that employ on-line monitoring tech-
niques for failure detection and identification, followed by
failure resolution external to the monitored system. Projects
in the DARPA DASADA program [15, 16] describe an
architecture that uses probes and gauges to monitor the
execution of programs, generate events containing mea-
surements, and take actions based on the interpretation of
events. Effectors interact with the system to ensure that
system’s run-time behavior fits within the envelope of ac-
ceptable behavior. Authors in [17] propose the generation
of proxies and wrappers to add autonomic functionalities
to object-oriented applications to cope with failures with-
out source code adaptation. In [18], authors describe the
use of code transformation to instrument Java byte-code by
adding fault analysis and healing actions. Authors in [7]
present a connector-based self-healing mechanism for soft-
ware components. A component in a self-healing system
is designed as a layered architecture, structured with the
healing layer and the service layer. The role of connectors
between tasks in a component is extended to support the
self-healing mechanism in detecting, re-configuring, and re-
pairing anomalous objects in components. In our proposed
approach, we separate the autonomic capabilities from base
model functionalities and use the modeling framework to
integrate the self-* specifications with functional specifica-
tions.
A fault tolerant network usually refers to a network that
is resilient against the failure of its component such as a
network element, for example, a router or a base station
controller. However, the dependability of a telecommuni-
cation network system rely on not only the reliability and
availability of its hardware components but also the surviv-
ability and sustainability of its software components. It has
been proposed in the past that fault tolerance could be de-
signed into system architecture to improve the network re-
liability and performance [19]. A variety of service failures
and hardware failures are pre-defined and associated with
well-categorized faults and then addressed by fault isola-
tion, detection, and restoration [20]. Although some of the
issues with software failures can be tackled using service
replication as proposed by the authors in [21], adaptable on-
line monitoring and self-healing approaches are yet rarely
defined for software failures simply because many of un-
expected and unforeseen software failures can only be de-
tected during run-time execution.
The IEEE Standard Classification for Software Anoma-
lies [22] provides a comprehensive list of software anomaly
classification and related data items that are helpful to iden-
tify and track anomalies. The methodology of this standard
is based on a process (sequence of steps) that pursues a log-
ical progression from the initial recognition of an anomaly
to its final disposition. [23] describes the taxonomy of fail-
ures, errors, and faults for dependable and secure computing
as a basis for attaining dependability and security. In [24],
tree-based techniques are proposed for the classification of
software failures based on execution profiles. The UML
profile for modeling QoS and fault tolerance [7] defines a
set of UML extensions to represent QoS and fault tolerance
concepts based on object replications.
The novelty of our model based approach for adding self-
healing functionality to network fault management system
lies in the modeling framework to integrate the self-* spec-
ifications with functional specifications, as well as the ap-
plication of model integration to realize these capabilities.
The presented modeling framework aims to be more general
than the prior approaches in that we synthesize self-healing
techniques and employ model composition and transforma-
tion mechanisms to support adding autonomic capabilities
to software systems from the abstract model specifications
down to the low-level system implementations.
6 Conclusion
Autonomic aspects like self-monitoring, self-healing,
and self-adjusting are highly desirable capabilities to meet
the dependability requirements for network fault manage-
ment systems. We propose a model based approach to
retrofit a network fault management system with a moni-
tor and control loop to achieve self-healing. Although our
work focuses on network fault management, we believe the
modeling framework can be generalized to add autonomic
capabilities extensively for legacy systems in other applica-
tion domains.
Our future work will be focused on modeling and de-
ploying policy directed self-* capabilities in the context of
model based policy based network management [25], for in-
stance, specifying and modeling policies at high levels and
then mapping them with various parameters and constraints
17
for self-healing operations, all of which will be based on
more general and advanced techniques for failure predic-
tion, classification, reasoning, and intelligent strategy se-
lection for risk mitigation.
References
[1] John Strassner and Jeffrey O. Kephart. Autonomic
systems and networks: Theory and practice. In Pro-
ceeding of the Network Operations and Management
Symposium (NOMS) 2006, 2006.
[2] Jeffrey O. Kephart and David M. Chess. The vision of
autonomic computing. IEEE Computer, 36(1), 2003.
[3] Yan Liu, Jing Zhang, Michael Jiang, David Raymer,
and John Strassner. A model-based approach to
adding autonomic capabilities to network fault man-
agement system. In to be published in Proceedings of
the IEEE/IFIP Network Operations and Management
Symposium 2008, Salvardo, Brazil, 2008.
[4] Rakesh Agrawal, Tomasz Imielinski, and Arun
Swami. Mining association rules between sets of
items in large databases. SIGMOD, 22(2), 1993.
[5] Rakesh Agrawal and Ramakrishnan Srikant. Fast al-
gorithms for mining association rules. VLDB, 22(2),
1994.
[6] Object Management Group. Uml profile for model-
ing quality of service and fault tolerance character-
istics and mechanisms. http://www.omg.org/
cgi-bin/doc?formal/06-05-02, 2006.
[7] Michael E. Shin and Daniel Cooke. Connector-based
self-healing mechanism for components of a reliable
system. SIGSOFT Softw. Eng. Notes, 30(4):1–7, 2005.
[8] John Strassner. Policy-Based Network Management:
Solutions for the Next Generation (The Morgan Kauf-
mann Series in Networking). Morgan Kaufmann Pub-
lishers Inc., San Francisco, CA, USA, 2003.
[9] Vina Ermagan, Jun ichi Mizutani, Kentaro Oguchi,
and David Weir. Towards model-based failure-
management for automotive software. In SEAS ’07:
Proceedings of the 4th International Workshop on
Software Engineering for Automotive Systems, page 8,
Washington, DC, USA, 2007. IEEE Computer Soci-
ety.
[10] David John Pumfrey. The principled design of com-
puter system safety analyses. Department of Com-
puter Science, University of York, 2000. PhD Thesis.
[11] Yennun Huang, Chandra Kintala, Nick Kolettis, and
N. Dudley Fulton. Software rejuvenation: analy-
sis, module and applications. In Twenty-Fifth In-
ternational Symposium on Fault-Tolerant Computing,
FTCS-25. Digest of Papers, volume 30, pages 381–
390, 1995.
[12] Aspect-oriented modeling. http://www.
aspect-modeling.org/.
[13] Gregor Kiczales, John Lamping, Anurag Menhd-
hekar, Chris Maeda, Cristina Lopes, Jean-Marc Lo-
ingtier, and John Irwin. Aspect-oriented program-
ming. In Proceedings European Conference on
Object-Oriented Programming, volume 1241, pages
220–242. Springer-Verlag, 1997.
[14] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik
Kersten, Jeffrey Palm, and William Griswold. Get-
ting started with aspectj. Communications of ACM,
44(10):59–65, 2001.
[15] David Garlan, Bradley Schmerl, and Jichuan Chang.
Using gauges for architecture-based monitoring and
adaptation. December 2001.
[21] Rachid Guerraoui and André Schiper. Software-based
replication for fault tolerance. Computer, 30(4):68–
74, 1997.
[22] Roy Sterritt and Michael G. Hinchey. Autonomicity -
an antidote for complexity? pages 283–291, 2005.
[23] IEEE standard classification for software anomalies,
1993.
[24] Patrick Francis, David Leon, Melinda Minch, and
Andy Podgurski. Tree-based methods for classify-
ing software failures. In ISSRE ’04: Proceedings of
the 15th International Symposium on Software Relia-
bility Engineering (ISSRE’04), pages 451–462, Wash-
ington, DC, USA, 2004. IEEE Computer Society.
[25] Dave Raymer, John Strassner, Elyes Lehtihet, and
Sven van der Meer. End-to-end model driven pol-
icy based network management. In POLICY ’06:
Proceedings of the Seventh IEEE International Work-
shop on Policies for Distributed Systems and Networks
(POLICY’06), pages 67–70, Washington, DC, USA,
2006. IEEE Computer Society.

[16] Janak Parekh, Gail Kaiser, Philip Gross, and Giuseppe

Valetto. Retrofitting autonomic capabilities onto
legacy systems. Cluster Computing, 9(2):141–159,
2006.

[17] A.R. Haydarlou, B.J. Overeinder, and F.M.T. Brazier.

A self-healing approach for object-oriented applica-
tions. In Proceedings. of Sixteenth International Work-
shop on Database and Expert Systems Applications,
pages 191–195, 2005.

[18] M. Muztaba Fuad and Michael J. Oudshoorn. Trans-

formation of existing programs into autonomic and
self-healing entities. In ECBS ’07: Proceedings of
the 14th Annual IEEE International Conference and
Workshops on the Engineering of Computer-Based
Systems, pages 133–144, Washington, DC, USA,
2007. IEEE Computer Society.

[19] Tomohiro Fujisaki, Masaki Hamada, and Katsuyoshi

Kageyama. A scalable fault-tolerant network man-
agement system built using distributed object technol-
ogy. In EDOC ’97: Proceedings of the 1st Interna-
tional Conference on Enterprise Distributed Object
Computing, pages 140–148, Washington, DC, USA,
1997. IEEE Computer Society.

[20] D. Medhi. Network reliability and fault tolerance,

1999.

18