2.2 Approaches to Achieving Dependability

2 Requirements

2.2 Approaches to Achieving Dependability

Achieving the goal of dependability requires effort at all phases of a system's development. Steps must be taken at design time, implementation time, and execution time, as well as during maintenance and enhancement. At design time, we can increase the dependability of a system through fault avoidance techniques. At implementation time, we can increase the dependability of the system through fault removal techniques. At execution time, fault tolerance and fault evasion techniques are required.

2.2.1 Fault Avoidance

Fault avoidance uses various tools and techniques to design the system in such a manner that the introduction of faults is minimized. A fault avoided is one that does not have to be dealt with at a later time. Techniques used include design methodologies, verification and validation methodologies, modelling, and code inspections and walk-throughs.

2.2.2 Fault Removal

Fault removal uses verification and testing techniques to locate faults enabling the necessary changes to be made to the system. The range of techniques used for fault removal includes unit testing, integration testing, regression testing, and back-to-back testing. It is generally much more expensive to remove a fault than to avoid a fault.

2.2.3 Fault Tolerance

In spite of the best efforts to avoid or remove them, there are bound to be faults in any operational system. A system built with fault tolerance capabilities will manage to keep operating, perhaps at a degraded level, in the presence of these faults. For a system to be fault tolerant, it must be able to detect, diagnose, confine, mask, compensate and recover from faults. These concepts will be discussed thoroughly in Section 4 of this paper.

2.2.4 Fault Evasion

It is possible to observe the behavior of a system and use this information to take action to compensate for faults before they occur. Often, systems exhibit a characteristic or normal behavior. When a system deviates from its normal behavior, even if the behavior continues to meet system specifications, it may be appropriate to reconfigure the system to reduce the stress on a component with a high failure potential. We have coined the term fault evasion to describe this practice. For example, a bridge that sways as traffic crosses may not be exceeding specifications, but would warrant increased attention from a bridge inspector. Similarly, a computer system that suddenly begins to respond sluggishly often prompts a prudent user to backup any work in progress, even though overall system performance may be within specification.

2.2.1 - Fault Avoidance
2.2.2 - Fault Removal
2.2.3 - Fault Tolerance
2.2.4 - Fault Evasion

A Conceptual Framework for Systems Fault Tolerance - 30 MAR 95

[Next] [Previous] [Up] [Top]

Generated with CERN WebMaker