Critical systems development

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 1

Objectives


To explain how fault tolerance and fault avoidance contribute to the development of dependable systems To describe characteristics of dependable software processes To introduce programming techniques for fault avoidance To describe fault tolerance mechanisms and their use of diversity and redundancy

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 2

Topics covered
   

Dependable processes Dependable programming Fault tolerance Fault tolerant architectures

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 3

Software dependability


In general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures. Some applications, however, have very high dependability requirements and special software engineering techniques may be used to achieve this.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 4

Dependability achievement


Fault avoidance
The system is developed in such a way that human error is avoided and thus system faults are minimised. The development process is organised so that faults in the system are detected and repaired before delivery to the customer. Verification and validation techniques are used to discover and remove faults in a system before it is deployed. The system is designed so that faults in the delivered software do not result in system failure.

Fault detection

Fault tolerance

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 5

Diversity and redundancy



Redundancy
Keep more than 1 version of a critical component available so that if one fails then a backup is available. Provide the same functionality in different ways so that they will not fail in the same way.

Diversity

However, adding diversity and redundancy adds complexity and this can increase the chances of error. Some engineers advocate simplicity and extensive V & V is a more effective route to software dependability.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 6

Diversity and redundancy examples



Redundancy. Where availability is critical (e.g. in e-commerce systems), companies normally keep backup servers and switch to these automatically if failure occurs. Diversity. To provide resilience against external attacks, different servers may be implemented using different operating systems (e.g. Windows and Linux)

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 7

Fault-free software


Current methods of software engineering now allow for the production of fault-free software, at least for relatively small systems. Fault-free software means software which conforms to its specification. It does NOT mean software which will always perform correctly as there may be specification errors. The cost of producing fault free software is very high. It is only cost-effective in exceptional situations. It is often cheaper to accept software faults and pay for their consequences than to expend resources on developing fault-free software.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 8

Fault-free software development

      

Dependable software processes Quality management Formal specification Static verification Strong typing Safe programming Protected information

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 9

Fault removal costs

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 10

Dependable processes


To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process. A well-defined repeatable process is one that does not depend entirely on individual skills; rather can be enacted by different people. For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation.
Software Engineering, 7th edition. Chapter 20 Slide 11

Ian Sommerville 2004

Dependable process characteristics

Documentable The process should have a defined process model that sets out the activities in the process and the documentation that is to be produced during these activities. A comprehensive set of software development standards that define how the software is to be produced and documented should be available. The process should be understandable by people apart from process participants who can check that process standards are being followed and make suggestions for process improvement. The process should include redundant and diverse verification and validation activities. The process should be able to recover from failures of individual process activities.

Standardised

Auditable

Diverse Robust

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 12

Validation activities
      

Requirements inspections. Requirements management. Model checking. Design and code inspection. Static analysis. Test planning and management. Configuration management, discussed in Chapter 29, is also essential.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 13

Dependable programming


Use programming constructs and techniques that contribute to fault avoidance and fault tolerance
Design for simplicity; Protect information from unauthorised access; Minimise the use of unsafe programming constructs.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 14

Information protection


Information should only be exposed to those parts of the program which need to access it. This involves the creation of objects or abstract data types that maintain state and that provide operations on that state. This avoids faults for three reasons:
the probability of accidental corruption of information is reduced; the information is surrounded by firewalls so that problems are less likely to spread to other parts of the program; as all information is localised, you are less likely to make errors and reviewers are more likely to find errors.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 15

A queue specification in Java

inte rfa ce Q ueue { pu blic voi d put (Ob ject o) ; pu blic voi d re m ove (Ob je ct o ) ; pu blic in t siz e ( ) ; } //Queu e

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 16

Signal declaration in Java

cl ass Si gna l { stat ic p ub lic fina l i nt red = 1 ; stat ic p ub lic fina l i nt ambe r = 2 ; stat ic p ub lic fina l i nt gree n = 3 ; pu blic in t si g S tate ; }
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 17

Safe programming


Faults in programs are usually a consequence of programmers making mistakes. These mistakes occur because people lose track of the relationships between program variables. Some programming constructs are more error-prone than others so avoiding their use reduces programmer mistakes.
Software Engineering, 7th edition. Chapter 20 Slide 18

Ian Sommerville 2004

Structured programming


 

 

First proposed in 1968 as an approach to development that makes programs easier to understand and that avoids programmer errors. Programming without gotos. While loops and if statements as the only control statements. Top-down design. An important development because it promoted thought and discussion about programming.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 19

Error-prone constructs


Floating-point numbers
Inherently imprecise. The imprecision may lead to invalid comparisons. Pointers referring to the wrong memory areas can corrupt data. Aliasing can make programs difficult to understand and change. Run-time allocation can cause memory overflow. Can result in subtle timing errors because of unforeseen interaction between parallel processes. Errors in recursion can cause memory overflow.
Software Engineering, 7th edition. Chapter 20 Slide 20

Pointers

Dynamic memory allocation

Parallelism

Recursion

Ian Sommerville 2004

Error-prone constructs


Interrupts Interrupts can cause a critical operation to be terminated and make a program difficult to understand. Inheritance Code is not localised. This can result in unexpected behaviour when changes are made and problems of understanding. Aliasing Using more than 1 name to refer to the same state variable. Unbounded arrays Buffer overflow failures can occur if no bound checking on arrays. Default input processing An input action that occurs irrespective of the input.
Software Engineering, 7th edition. Chapter 20 Slide 21

Ian Sommerville 2004

Exception handling


A program exception is an error or some unexpected event such as a power failure. Exception handling constructs allow for such events to be handled without the need for continual status checking to detect exceptions. Using normal control constructs to detect exceptions needs many additional statements to be added to the program. This adds a significant overhead and is potentially error-prone.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 22

Exceptions in Java 1
c la s s Se ns orFa ilu reE xc ep tio n ex te nd s Ex ce ptio n { S en so rF ailu reEx ce pt ion (S trin g ms g) { s up er (m sg ) ; A la rm .a c tiva te (m sg ) ; } // S en so rF ai lureE xc ep tion

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 23

Exceptions in Java 2
c la ss S e nsor { in t rea dVa l ( ) th row s Se ns orFa ilu re E xcep tio n { try { in t the V a lu e = D e vice IO .r ea dI n te ge r () ; if (t he V a lu e < 0 ) th ro w new S en so rF ailu reE xc ep tion (" Se nsor fa ilu re ") ; re tu rn th eVa lu e ; } c at ch (d ev ic e IOE xc ep tion e ) { th ro w new S en so rF ailu reE xc ep tion ( S en so r rea d erro r ) ; } } // r e adV al // S en so r
Software Engineering, 7th edition. Chapter 20 Slide 24

Ian Sommerville 2004

A temperature controller


 

Exceptions can be used as a normal programming technique and not just as a way of recovering from faults. Consider an example of a freezer controller that keeps the freezer temperature within a specified range. Switches a refrigerant pump on and off. Sets off an alarm is the maximum allowed temperature is exceeded. Uses exceptions as a normal programming technique.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 25

Freezer controller 1
c la s s Free ze rC on trol ler { S en so r te mp Sen so r = n ew Se ns or () ; D ia l t em pD ia l = n ew D ia l () ; floa t f ree ze rTe m p = tem pSe ns or.r e adV al () ; fina l f loa t da ng erTem p = ( flo at) -18 .0 ; fina l l on g c oo ling Ti me = (lon g) 200 00 0.0 ; p ub lic v o id r un ( ) th row s In te rru pted E x cep tio n { try { P ump .s w itch It (P ump .o n ) ; do { if (f ree ze rT emp > tem pD ia l.s ettin g () ) if ( P ump .s ta tus = = Pum p. o ff) { P ump .s w itch It (P ump .o n ) ; T hrea d.sl e ep ( co ol ing Tim e ) ;

}
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 26

Freezer controller 2
if (f ree ze rT emp > d an ge rT emp ) th ro w new F re e ze rTo oH otE xcep tio n () ; free ze rTe m p = tem pSe ns or.r e adV al () ; } w h ile (tr u e) ; } // try block cat ch (F re ezerTo oHo tE xcep tio n f) { A la rm .a ctiva te ( ) ; } cat ch (I n te rrup te dE xc ep tion e ) { S ys te m .ou t.p rin tln (T hrea d ex ce ptio n ) ; th ro w new In te rr u ptedE xcep tio n ( ) ; } } // run } // F ree ze rC on tr o lle r

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 27

Fault tolerance


In critical situations, software systems must be fault tolerant. Fault tolerance is required where there are high availability requirements or where system failure costs are very high. Fault tolerance means that the system can continue in operation in spite of software failure. Even if the system has been proved to conform to its specification, it must also be fault tolerant as there may be specification errors or the validation may be incorrect.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 28

Fault tolerance actions



Fault detection
The system must detect that a fault (an incorrect system state) has occurred. The parts of the system state affected by the fault must be detected. The system must restore its state to a known safe state. The system may be modified to prevent recurrence of the fault. As many software faults are transitory, this is often unnecessary.

Damage assessment

Fault recovery

Fault repair

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 29

Fault detection and damage assessment



The first stage of fault tolerance is to detect that a fault (an erroneous system state) has occurred or will occur. Fault detection involves defining constraints that must hold for all legal states and checking the state against these constraints.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 30

Insulin pump state constraints

// T he dos e o f in s ulin t o be d eliv e re d m us t a lw ay s be g re a te r // t h an z ero an d les s tha t so m e d efin ed m ax im um si n gle do se in su lin _do se > = 0 & i ns ul in_ do se < = in su lin _res ervo ir_ co nten ts // T he to ta l a m ou nt of in su lin d el ive re d in a da y mu st be l es s // t h an o r e qua l t o a d efin ed da ily ma xi mu m do se c um ulativ e _do se < = ma xim um _da ily _d os e

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 31

Fault detection


Preventative fault detection

The fault detection mechanism is initiated before the state change is committed. If an erroneous state is detected, the change is not made. The fault detection mechanism is initiated after the system state has been changed. This is used when a incorrect sequence of correct actions leads to an erroneous state or when preventative fault detection involves too much overhead.
Software Engineering, 7th edition. Chapter 20 Slide 32

Retrospective fault detection

Ian Sommerville 2004

Type system extension



Preventative fault detection really involves extending the type system by including additional constraints as part of the type definition. These constraints are implemented by defining basic operations within a class definition.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 33

PositiveEvenInteger 1
c la s s Po sitiv eE ve nInteg er { in t v al = 0 ; P os iti ve Ev en In te ge r (in t n ) t h row s Num er icE xc ep tion { if (n < 0 | n%2 = = 1 ) th ro w new N ume ric Ex ce ptio n () ; e ls e v al = n ; }// P os itive E ve nI n te ge r

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 34

PositiveEvenInteger 2
p ub lic vo id a ss ig n ( in t n ) th rows N ume ric Ex ce ptio n { if (n < 0 | n%2 = = 1 ) th ro w new N ume ric Ex ce ptio n (); e ls e v al = n ; } // as si g n in t toI n teg er () { re tu rn va l ; } //t o Int eg er b oo le an e qu al s ( P o sitiv eE ve nInteg er n ) { re tu rn (v al == n .v al ) ; } // eq ua ls } //P os itive Eve n

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 35

Damage assessment


Analyse system state to judge the extent of corruption caused by a system failure. The assessment must check what parts of the state space have been affected by the failure. Generally based on validity functions that can be applied to the state elements to assess if their value is within an allowed range.
Software Engineering, 7th edition. Chapter 20 Slide 36

Ian Sommerville 2004

Robust array 1
c la s s R o bus tA rra y { // C he ck s tha t a ll th e ob je c ts in a n ar ray o f o bjec ts // c o nform to s om e de fin ed c on stra in t b oo le an [] c h ec kS ta te ; C he ckab leO bj e ct [] th eRo bu stA rra y ; R ob ustA rray (Ch ecka bl eO bject [] the A rra y ) { c he ck Stat e = n ew bo ol e an [ th eA rra y.le ng th ] ; th eRo bu stArra y = t he A rra y ; } //R obu st A rray
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 37

Robust array 2
p ub lic v o id a ss es sDa m ag e () thr ow s A rra yD ama ge dEx ce ptio n { b oo le an h as B e enD ama ge d = fa lse ; fo r (in t i= 0 ; i <this. theR ob us tA rr a y.le ng th ; i ++ ) { if (! t h eR obu st A rray [i].c he c k ()) { c he ck S tat e [ i] = t ru e ; h as B e enD ama ge d = tru e ; } e ls e c he ck S tat e [ i] = f al s e ; } if (h as B ee nD ama ged ) th ro w new A rr a yDa m ag ed E x cep tio n () ; } //a ss es sDa m ag e } // Ro bu stA rra y

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 38

Damage assessment techniques



Checksums are used for damage assessment in data transmission. Redundant pointers can be used to check the integrity of data structures. Watch dog timers can check for nonterminating processes. If no response after a certain time, a problem is assumed.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 39

Fault recovery and repair



Forward recovery
Apply repairs to a corrupted system state. Restore the system state to a known safe state.

Backward recovery

Forward recovery is usually application specific - domain knowledge is required to compute possible state corrections. Backward error recovery is simpler. Details of a safe state are maintained and this replaces the corrupted system state.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 40

Forward recovery


Corruption of data coding

Error coding techniques which add redundancy to coded data can be used for repairing data corrupted during transmission. When redundant pointers are included in data structures (e.g. two-way lists), a corrupted list or filestore may be rebuilt if a sufficient number of pointers are uncorrupted Often used for database and file system repair.

Redundant pointers

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 41

Backward recovery


Transactions are a frequently used method of backward recovery. Changes are not applied until computation is complete. If an error occurs, the system is left in the state preceding the transaction. Periodic checkpoints allow system to 'rollback' to a correct state.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 42

Safe sort procedure



 

A sort operation monitors its own execution and assesses if the sort has been correctly executed. It maintains a copy of its input so that if an error occurs, the input is not corrupted. Based on identifying and handling exceptions. Possible in this case as the condition for avalid sort is known. However, in many cases it is difficult to write validity checks.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 43

Safe sort 1
c la s s Sa fe So rt { sta tic v o id s o rt ( int [] in tarra y, int orde r ) th row s So rt E rror { in t [] cop y = ne w in t [int a rray.le ng th ]; // co py t he in pu t ar ray fo r (in t i = 0; i < in ta rr a y.le ng th ; i++ ) c op y [i] = i nt a rray [i] ; try { S ort.b ub ble so rt (in ta rr a y, in ta rr a y.le ng th , o rd er ) ;

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 44

Safe sort 2
if (o rd er == So rt. a sce nd in g ) fo r (in t i = 0; i < = in tarra y. len gth- 2 ; i+ +) if (i n ta rr a y [i] > i n ta rra y [i+ 1 ]) th ro w new S or tE rro r () ; e ls e fo r (in t i = 0; i < = in tarra y. len gth- 2 ; i+ +) if (i n ta rr a y [i+ 1] > in ta rr a y [i]) th ro w new S or tE rro r () ; } // try bloc k c at c h (S ortE rr o r e ) { fo r (in t i = 0; i < in ta rr a y.le ng th ; i++ ) in ta rr a y [i] = co py [i] ; th ro w new S or tE rro r ("A rra y no t s orte d ") ; } //c atch } // s or t } // Sa fe S o rt

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 45

Fault tolerant architecture



Defensive programming cannot cope with faults that involve interactions between the hardware and the software. Misunderstandings of the requirements may mean that checks and the associated code are incorrect. Where systems have high availability requirements, a specific architecture designed to support fault tolerance may be required. This must tolerate both hardware and software failure.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 46

Hardware fault tolerance

 

Depends on triple-modular redundancy (TMR). There are three replicated identical components that receive the same input and whose outputs are compared. If one output is different, it is ignored and component failure is assumed. Based on most faults resulting from component failures rather than design faults and a low probability of simultaneous component failure.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 47

Hardware reliability with TMR

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 48

Output selection


The output comparator is a (relatively) simple hardware unit. It compares its input signals and, if one is different from the others, it rejects it. Essentially, the selection of the actual output depends on the majority vote. The output comparator is connected to a fault management unit that can either try to repair the faulty unit or take it out of service.
Software Engineering, 7th edition. Chapter 20 Slide 49

Ian Sommerville 2004

Fault tolerant software architectures



The success of TMR at providing fault tolerance is based on two fundamental assumptions
The hardware components do not include common design faults; Components fail randomly and there is a low probability of simultaneous component failure. It isnt possible simply to replicate the same component as they would have common design faults; Simultaneous component failure is therefore virtually inevitable.

Neither of these assumptions are true for software

Software systems must therefore be diverse.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 50

Design diversity


Different versions of the system are designed and implemented in different ways. They therefore ought to have different failure modes. Different approaches to design (e.g object-oriented and function oriented)
Implementation in different programming languages; Use of different tools and development environments; Use of different algorithms in the implementation.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 51

Software analogies to TMR



N-version programming
The same specification is implemented in a number of different versions by different teams. All versions compute simultaneously and the majority output is selected using a voting system. This is the most commonly used approach e.g. in many models of the Airbus commercial aircraft. A number of explicitly different versions of the same specification are written and executed in sequence. An acceptance test is used to select the output to be transmitted.

Recovery blocks

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 52

N-version programming

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 53

Output comparison


As in hardware systems, the output comparator is a simple piece of software that uses a voting mechanism to select the output. In real-time systems, there may be a requirement that the results from the different versions are all produced within a certain time frame.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 54

N-version programming


The different system versions are designed and implemented by different teams. It is assumed that there is a low probability that they will make the same mistakes. The algorithms used should but may not be different. There is some empirical evidence that teams commonly misinterpret specifications in the same way and chose the same algorithms in their systems.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 55

Recovery blocks

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 56

Recovery blocks


These force a different algorithm to be used for each version so they reduce the probability of common errors. However, the design of the acceptance test is difficult as it must be independent of the computation used. There are problems with this approach for real-time systems because of the sequential operation of the redundant versions.
Software Engineering, 7th edition. Chapter 20 Slide 57

Ian Sommerville 2004

Problems with design diversity



Teams are not culturally diverse so they tend to tackle problems in the same way. Characteristic errors
Different teams make the same mistakes. Some parts of an implementation are more difficult than others so all teams tend to make mistakes in the same place; Specification errors; If there is an error in the specification then this is reflected in all implementations; This can be addressed to some extent by using multiple specification representations.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 58

Specification dependency


Both approaches to software redundancy are susceptible to specification errors. If the specification is incorrect, the system could fail This is also a problem with hardware but software specifications are usually more complex than hardware specifications and harder to validate. This has been addressed in some cases by developing separate software specifications from the same user specification.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 59

Key points


Dependability in a system can be achieved through fault avoidance, fault detection and fault tolerance. The use of redundancy and diversity is essential to the development of dependable systems. The use of a well-defined repeatable process is important if faults in a system are to be minimised. Some programming constructs are inherently errorprone - their use should be avoided wherever possible.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 60

Key points


Exceptions are used to support error management in dependable systems. The four aspects of program fault tolerance are failure detection, damage assessment, fault recovery and fault repair. N-version programming and recovery blocks are alternative approaches to fault-tolerant architectures.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 20

Slide 61