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

Slides:



Advertisements
Similar presentations
Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
Advertisements

SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Software Failure: Reasons Incorrect, missing, impossible requirements * Requirement validation. Incorrect specification * Specification verification. Faulty.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Theoretical Program Checking Greg Bronevetsky. Background The field of Program Checking is about 13 years old. Pioneered by Manuel Blum, Hal Wasserman,
Unit 251 Implementation and Integration Implementation Unit Testing Integration Integration Approaches.
8. Fault Tolerance in Software 8.1 Introduction Is it true that a program that has once performed a given task as specified will continue to do so? Yes,
DS -V - FDT - 1 HUMBOLDT-UNIVERSITÄT ZU BERLIN INSTITUT FÜR INFORMATIK Zuverlässige Systeme für Web und E-Business (Dependable Systems for Web and E-Business)
Software Testing and Quality Assurance
Marakas: Decision Support Systems, 2nd Edition © 2003, Prentice-Hall Chapter Chapter 1: Introduction to Decision Support Systems Decision Support.
Testing an individual module
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Design of SCS Architecture, Control and Fault Handling.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
Course Instructor: Aisha Azeem
Software Engineering Lecture 12 Software Testing Techniques 1.
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 13 & 14 Software Testing Strategies and Techniques
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Fundamentals of Python: From First Programs Through Data Structures
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Fundamentals of Python: First Programs
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Integration testing l Tests complete systems or subsystems composed of integrated.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CMSC 345 Fall 2000 Unit Testing. The testing process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
CS, AUHenrik Bærbak Christensen1 Fault Tolerant Architectures Lyu Chapter 14 Sommerville Chapter 20 Part II.
WXGE6103 Software Engineering Process and Practice Formal Specification.
Dr. Tom WayCSC Testing and Test-Driven Development CSC 4700 Software Engineering Based on Sommerville slides.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Fault-Tolerant Systems Design Part 1.
SENG521 (Fall SENG 521 Software Reliability & Testing Fault Tolerant Software Systems: Techniques (Part 4b) Department of Electrical.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CprE 458/558: Real-Time Systems
Fault-Tolerant Systems Design Part 1.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
Theory and Practice of Software Testing
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
18/05/2006 Fault Tolerant Computing Based on Diversity by Seda Demirağ
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Week#3 Software Quality Engineering.
Software Quality Assurance
Formal Specification.
CompSci 280 S Introduction to Software Development
Software Testing.
Software Testing.
Software Testing Techniques
Chapter 13 & 14 Software Testing Strategies and Techniques
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing (Lecture 11-a)
Chapter 14 Software Testing Techniques
Testing and Test-Driven Development CSC 4700 Software Engineering
Chapter 10 – Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Chapter 29: Program Security
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

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

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

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

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

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

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

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.

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

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

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

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?

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

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

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

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

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

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)

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.

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)

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)

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

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

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))}

Data Re-expression Identical output set

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.

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.

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.

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