Developing Dependable Systems CIS 376 Bruce R Maxim UM Dearborn Software Dependability Customers expect all software to be dependable They may accept some system failures in non critical applications Applications having high dependability requirements require special programming techniques Achieving Dependability Fault avoidance software developed to minimize impact of human error development process is organized so that faults in the software are detected and repaired before customer delivery Fault tolerance software designed so that faults in delivered software do not cause system failure Fault Minimization Current SE methods can produce fault free software Fault free software merely conforms to its specification it may or may not always perform correctly since the specification may be flawed The cost of producing fault free software is very expensive and may only be justified in exceptional situations It may be cheaper to accept some software faults Developing Fault Free Software Needs a precise preferably formal specification Requires an organizational commitment to quality Information hiding and encapsulation in software design are essential A programming language with strict type checking and run time checking should be used Needs a dependable and repeatable development process Error Prone Constructs part 1 Floating point numbers inherently imprecise frequent comparison errors Pointers Dangling references and aliases possible Dynamic Memory Allocation memory overflow and garbage problems Parallelism race conditions and deadlocks are possible Error Prone Constructs part 2 Recursion memory overflow when errors occur Interrupts errors are difficult to trace Inheritance code is no longer localized unexpected results can arise when changes are made Note You can use these constructs as needed but you must be careful to use them correctly Information Hiding Information should only be available to program components on a need to know basis reduces the probability of accidental corruption of information information is encapsulated to prevent error propagation to rest of program since information is localized programmer is less likely make errors and reviewers are more likely to find errors Reliable Software Processes Having a well defined repeatable software process will reduce the number of software faults A well defined repeatable process is one that does not depend entirely on individual skills but can be carried out by a team Significant verification and validation process activities must included to minimize the number of software faults Process Validation Activities Requirements inspections Requirements management Model checking Design inspections Code inspections Static code analysis Test planning and management Configuration management Fault Tolerance Required in critical applications high reliability needed and high failure costs System can continue operation despite software failure A system which seems to be fault free must also be fault tolerant in case specification errors exist or the validation is incorrect Fault Tolerant Actions Fault detection system determines an incorrect system state has occurred Damage assessment determine system parts affected by fault Fault recovery system must restore its state to a known safe state Fault repair for a non transitory fault system is modified to prevent repetition Approaches Defensive Programming programmers assume faults exist in system code redundant code is written to check system state for consistency after modification are made Fault Tolerant Architectures HW and SW architectures that support redundancy are used a fault tolerance controller that detects problems and supports recovery Both approaches are important Exception Management Could be program error or an event like power failure Exception handling facilities in programming languages allow exceptions to be handled without constant checking to detect them Using normal control constructs to detect exceptions in a sequence of procedural calls adds considerable timing overhead to a program Fault Detection Languages with strict type checking allow many errors to be trapped during program compilation Some types of errors can only be caught at run time e g cin I cin A I Fault Detection Approaches Preventative Fault Detection fault detection mechanism is activated before a state change is committed if an erroneous state is detected change is cancelled Retrospective Fault Detection fault detection mechanism is initiated after system state change has been made used when correct sequence of actions can lead to erroneous system state or preventative fault detection has too much overhead Type System Extension Preventative fault detection really involves extending the current type system by including additional constraints as part of the type definition These constraints are typically implemented by defining basic operations within a class definition Damage Assessment System is analyzed to judge the extent of corruption caused by a system failure Must determine what parts of the state space have been affected by the failure Generally based on validity functions which can be applied to the state elements to assess if their value is within an allowed range Damage Assessment Techniques Checksums are used to check for data transmission errors Redundant pointers can be used to check integrity of data structures Watch dog timers can help check for nonterminating processes e g long time with no response assume the worst Fault Recovery Forward Recovery apply repairs to corrupted system state usually application specific requires domain knowledge e g error coding like check sum added to data Backward Recovery restore system to known safe state simpler since archived safe state is used to replace erroneous state e g use of checkpoints in WP editor Fault Tolerant Architecture Defensive programming can not cope faults caused by HW and SW interactions If requirements are not understood then SW checks are not likely to be correct Systems with high availability requirements often require fault tolerant architectures Must tolerate both HW and SW failure Hardware Fault Tolerance Triple modular redundancy TMR Three replicated component are included in the system If one component produces different output than the other two failure is assumed This idea is based on the notion that most failures result from component failures not design faults Component failures should be a low probability event