What is Software Robustness? Principles, Fault Detection and Treatment – Binary Terms

Software robustness is a quality check that reveals how much software is tolerant to faults. No software can proclaim to be faultless, every software has some or the other fault. But in your day to day life whenever you use software, you are never worried about its malfunction or about the correctness of the result provided by the software. This is because software is thoroughly tested through all the parameters before it is delivered to the customer.

The software faults can either be a hardware failure, user error or a software bug. In the section ahead, we will discuss how we identify the robustness of the software. How does robust software deal with the faults?

Content: Software Robustness

What is Software Robustness in Software Engineering?

Software robustness is a quality check that helps us in identifying whether the software is tolerant to all kinds of faults or not. On the basis of their source we can classify faults into three types:

1. Hardware Fault – Such as disk failure or failure of a telecommunication line, etc.
2. Software Fault – Such as a bug in the software.
3. User Fault – Entering the data in a different format than expected.

To deal with the different kinds of faults hardware and software collaborate in a kind of symbiosis.

• Sometimes the hardware detects the software fault and sometimes the software detects the hardware fault.
• When a hardware fault occurs, the software copes up with the situation.
• In some systems, the software is responsible to cope up with user faults.

The main feature of robust software is that the system keeps going even if the faults occur. The faults are inevitable and there must be some means to cope up with the faults. On the basis of how the faults occur we can classify them into two categories:

1. Anticipated Faults
2. Unanticipated Faults

The anticipated fault is one that we can predict easily and it occurs occasionally.  Such as division by zero, floating-point overflow, opening a file that does not exist, etc.

An unanticipated fault is one that we cannot identify or predicted neither we can name it. Such as unpredictable hardware faults (I/O device error, memory fault, etc.), software default (bug), array subscript outside the allowed range, etc.

Principles of Robust Software

A robust software emphasis on the list of principles as discussed below:

• Observability – Software must display the information that guides the user about what is going on in the system.
• Recoverability – Software must be able to recover from the faults that have occurred.
• Responsiveness – In case the fault occurs the software must respond within a certain time limit.
• Task Conformance – A software must be able to perform each function that the user needs to do. No facility that the software proclaims must be missing.

How a robust software detects the fault?

We have categorized faults into hardware, software and user fault. If we talk about fault detection, it can either be detected by the software or the hardware.

Fault Detection by Software

Some faults can be identified or prevented from occurring while the software is being developed. For this the developer needs to follow the techniques below:

• Implementing a good design.
• Using an effective compiler to compile the software code.
• Performing a run-time check.
• Performing systematic testing of each function of the software.

Compile-time checking detects the faults such as:

• Misspelt name for functions or variables.
• Type inconsistency.
• An instruction accessing a variable out of scope.

Run-time checking detects the faults such as:

• Division by zero.
• An array is subscripts out of the scope of the array.

Fault Detection by Hardware

The hardware is capable of identifying the software as well as hardware faults such as:

Software Faults

• Division by zero.
• An array subscript is out of the scope of the array.
• A program or an instruction trying to access the restricted memory location.

Hardware Faults

• Device timeouts.
• Communication line faults.
• Memory parity checks

How does robust software deal with the damage?

A robust software must be able to cope up with the fault that occurred. In robust software, the processing of the system must not get affected by the occurrence of a fault and the system must keep going. So, the software must be able to deal with the damages that are consequences of the fault that occurred. To deal with the damage one must know the extent of the damage and the way to repair the damage.

To recover the damage, we have two alternative strategies:

1. Forward error recovery
2. Backward error recovery

Where do these recovery mechanisms apply?

In the forward error recovery mechanism, the system continues processing, in the way it repairs the damage and again resumes back to the normal processing.

The forward error recovery mechanism is useful to treat the anticipated faults. As the anticipated fault is predictable and we know its effect, we can plan its recovery beforehand. So, whenever the fault occurs, the system treats the fault and resumes back to its normal processing.

In the backward error recovery mechanism at a periodic interval, snapshots of the system (periodic dump) are taken, we refer to it as a recovery point. These recovery points have information about the data that is being changed. The system rolls back to the most recent recovery point whenever the fault occurs and then resumes the processing.

The backward error recovery mechanism is suitable to tread the unanticipated fault. This is because the unanticipated faults are not predictable and hence we can not plan its recovery in advance. So in case the unanticipated fault occurs, the system will roll back to the most recent recovery point.

This is all about the software robustness, which reveals how much the software is tolerant of any fault. We have also studied how robust software is tested to detect faults and how it deals with those faults.