1. Structuring Redundancy for Fault Tolerance Chapter 2 Designed by: Hadi Salimi Instructor: Dr. Mohsen Sharifi

2. Redundancy It was noted that redundancy alone is not sufficient for tolerance of software design faults some form of diversity must accompany the redundancy

3. Robustness Extent to which software can continue to operate correctly despite the introduction of invalid inputs Robust Software Approach does not use redundancy

4. Robustness (cont.) Robust software handles the following: – Out of range inputs – Inputs of the wrong type – Inputs in the wrong format

5. Robust Software Valid Input ? Request new input Use last acceptable value Use predefined value Raise Exception Continue Software Operation Handle Exception true false

6. Self-Checking Software Testing input data by error detecting code or data type checks Testing the control sequences by setting bounds on loop iterations Testing the function of the process by performing reasonableness check on the output

7. Pros and Cons Pros – Errors are detected early in test process Cons – Its checks are specific to input-related faults, so it usually cannot detect and tolerate any other less specific faults.

8. Design Diversity Informally: ‘Two heads are better than one’ or ‘Don’t put all your eggs in one basket’ – basic intuitions about diversity in many real-world contexts Long been used by engineers to improve dependability – e.g. functional diversity in some safety systems – also used for supporting claims for reliability and/or safety

9. Design Diversity (cont.) Design diversity is the provision of identical services through separate design and implementations These different components are alternatively called modules, versions, variants, or alternatives The goal is that at least one variant be operational all the times

10. Design Diversity (cont.) Variant 1Variant 2Variant n Decide r …. Correct Incorrect

11. Design Diversity (cont.) When significant independence in the variants' failure profile can be achieved, a simple adjudicator can be used Completely independent development cannot be achieved in practice So, Is design diversity costly?

12. Cost of Diversity A study on industrial software showed that the cost of a design diverse variant is about 0.8 times of the cost of a non-diverse software module. Some parts of the process are performed separately – detailed design, coding and testing others are performed for the software system as a whole – Like specifications, high-level design and system tests

13. Levels of Diversity At what level of detail to decompose the system into modules that will be diversified Small components are generally less complex, and their use leads to adjudicators, that are easier to handle Larger components, however, are more favorable for effective diversity. Those places where a decision takes place (decision points) are "non-diversity" points and must be limited

14. Levels of Diversity (cont.) Diversity can be applied to several layers of the system – Hardware – Application software – System software – Operators – interfaces between these components. When diversity is applied to more than one of these layers, it is generally termed multilayer diversity. – Cost – Speed

15. Data Diversity The data diverse techniques are meant to complement, rather than replace, design diverse techniques It is used to obtain alternate (or diverse) input data by generating logically equivalent input data sets

16. Some Definitions Failure Domain: – Is the set of input points that cause program failure Failure region: – is the geometry of the failure domain. It describes the distributions of points in the failure domain and determines the effective­ness of data diversity

17. Data Re-expression A Data Re-expression Algorithm (DRA) tries to produce data points that lie outside of a failure region, given an initial data point within a failure region. Input Set x y Failure Region y = R(x)

18. Data Re-expression (cont.) The performance of the DRA is much more important than the program structure (NCP, RtB) in which it is embedded Not all applications can employ data diversity. Those that cannot do so include applications in which an effective DRA cannot be found.

19. Data Re-expression (cont.) A Data Re-expression Algorithm, R, transforms the original input x to produce the new input y = R(x) The input y may either approximate x or contain x's information in a different form The program, P, and R determine the relationship between P(x) and P(y)

20. Basic Data Re-expression The requirements for the DRA can be derived from characteristics of the outputs Re-expression y = R(x) Execute P x P(x) P(y)

21. Re-expression with Post-Execution A correction, A, is performed on P(y) to undo the distortion produced by the re-expression algorithm, R. x P(x) A(P(y)) Re-expression y = R(x) Execute P Adjust for Re-expression

22. Decomposition and Recombination An input x is decomposed into a related set of inputs and the program is then run on each of these related inputs and the results are then recombined Decompose X->x1,…,xn Execute P P(xn) Recombine P(xi) P(x1) P(x2) … P(x) F(P(xi)) x

23. Sets in the Output Space Valid Output Set {y| Valid (x,P(y))} Identical Output Set {y | Correct (x, P(y))} Failure Set {y | Not Valid (y, P(y))}

24. Data Re-expression Identical output set

25. Examples Intersection of line segments – a DRA could alter the representation of the input by multiplying the input by a non-singular matrix, then the distortion could be recovered by multiplying the program output by the inverse of the matrix. Sort Functions – to subtract each input data value from a value larger than all the input data values.

26. Examples (cont.) Computation of the sine function – sin(a+b) = sin(a).cos(b) + cos(a).sin(b) – cos(a) = sin(90-a) – sin(a+b) = sin(a).sin(90-b) + sin(90-a).sin(b) Sensor data – to introduce a low-intensity noise term into the sensor values used by a control system.

27. Temporal Diversity Temporal diversity involves the performance or occurrence of an event at dif­ferent times Temporal diversity can be an effective means of overcoming transient faults The temporary conditions that cause problems in one execution may be absent when the software is re-executed.

28. Sample illustration Receive Input Receive Input Receive Input Software execution Adjudicate Results Reject Accept Discard