CS 5032 L7 dependability engineering 2013
Download as PPTX, PDF2 likes1,738 views
This document discusses key aspects of dependability engineering including: achieving dependability through fault avoidance, detection, and tolerance; using redundancy and diversity; the importance of well-defined, repeatable processes; and guidelines for dependable programming such as checking inputs, handling exceptions, avoiding error-prone constructs, and including timeouts. Critical systems often have high dependability requirements and their development must convince regulators that the system is dependable, safe, and secure.
CS 5032 L7 dependability engineering 2013
- 1. Dependability engineering Lecture 1 Dependability engineering 1, 2013 Slide 1
- 2. Software dependability • Software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures. • Some critical systems have very high dependability requirements and special software engineering techniques may be used to achieve this. – Medical systems – Telecommunications and power systems Dependability engineering 1, 2013 – Aerospace systems Slide 2
- 3. 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. • Fault detection – Verification and validation techniques are used to discover and remove faults in a system before it is deployed. • Fault tolerance – The system is designed so that faults in the delivered software do not result in system failure. Dependability engineering 1, 2013 Slide 3
- 4. Regulated systems • Many critical systems are regulated systems, which means that their use must be approved by an external regulator before the systems go into service. – Nuclear systems – Air traffic control systems – Medical devices • A safety and dependability case has to be approved by the regulator. Therefore, critical systems development has to create the evidence to convince a regulator that the system is dependable, safe and secure. Dependability engineering 1, 2013 Slide 4
- 5. The increasing costs of residual fault removal Dependability engineering 1, 2013 Slide 5
- 6. Diversity and redundancy • Redundancy – Keep more than 1 version of a critical component available so that if one fails then a backup is available. • Diversity – Provide the same functionality in different ways so that they will not fail in the same way. • However, diversity adds complexity – more chance of errors. • Some engineers advocate simplicity and extensive V & V Dependability engineering 1, 2013 rather then redundancy. Slide 6
- 7. 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) Dependability engineering 1, 2013 Slide 7
- 8. 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. • Regulators use information about the process to check if good software engineering practice has been used. • For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation. Dependability engineering 1, 2013 Slide 8
- 9. Attributes of dependable processes Process characteristic Description 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. Standardized A comprehensive set of software development standards covering software production and documentation should be available. Auditable 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. Diverse The process should include redundant and diverse verification and validation activities. Robust The process should be able to recover from failures of individual process activities. Dependability engineering 1, 2013 Slide 9
- 10. Process diversity and redundancy • Process activities, such as validation, should not depend on a single approach, such as testing, to validate the system • Rather, multiple different process activities the complement each other and allow for cross-checking help to avoid process errors, which may lead to errors in the software Reviews Automated analysis Testing Dependability engineering 1, 2013 Slide 10
- 11. Validation activities • Requirements reviews. Reviews • Requirements management.Reviews Automated analysis • Formal specification. Automated analysis • System modeling Automated analysis • Design and code inspection.Reviews • Static analysis. Automated analysis • Test planning and management.Testing Dependability engineering 1, 2013 Slide 11
- 12. Dependable programming • Good programming practices can be adopted that help reduce the incidence of program faults. • These programming practices support – Fault avoidance – Fault detection – Fault tolerance Dependability engineering 1, 2013 Slide 12
- 13. Good practice guidelines for dependable programming Dependable programming guidelines 1. Limit the visibility of information in a program 2. Check all inputs for validity 3. Provide a handler for all exceptions 4. Minimize the use of error-prone constructs 5. Provide restart capabilities 6. Check array bounds 7. Include timeouts when calling external components 8. Name all constants that represent real-world values Dependability engineering 1, 2013 Slide 13
- 14. Control the visibility of information in a program • Program components should only be allowed access to data that they need for their implementation. This means that accidental corruption of parts of the program state by these components is impossible. Specification Data structure • You can control visibility by using abstract data types where the data representation is private and you only allow access to the data through predefined operations such as get () and put (). Dependability engineering 1, 2013 Slide 14
- 15. Check all inputs for validity Input Input Check Processing Processing Many programs behave unpredictably when presented with unusual inputs and, sometimes, these are threats to the security of the system. Dependability engineering 1, 2013 Slide 15
- 16. Validity checks • Range checks – Check that the input falls within a known range. • Size checks – Check that the input does not exceed some maximum size e.g. 40 characters for a name. • Representation checks – Check that the input does not include characters that should not be part of its representation e.g. names do not include numerals. • Reasonableness checks – Use information about the input to check if it is reasonable rather than an extreme value. Dependability engineering 1, 2013 Slide 16
- 17. Provide a handler for all exceptions • 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. Dependability engineering 1, 2013 Slide 17
- 18. Exception handling Dependability engineering 1, 2013 Slide 18
- 19. Exception handling • Three possible exception handling strategies – Signal to a calling component that an exception has occurred and provide information about the type of exception. – Carry out some alternative processing to the processing where the exception occurred. This is only possible where the exception handler has enough information to recover from the problem that has arisen. – Pass control to a run-time support system to handle the exception. • Exception handling is a mechanism to provide some fault tolerance Dependability engineering 1, 2013 Slide 19
- 20. Minimize the use of error-prone constructs • Program faults are usually a consequence of human error because programmers lose track of the relationships between the different parts of the system • This is exacerbated by error-prone constructs in programming languages that are inherently complex or that don’t check for mistakes when they could do so. • Therefore, when programming, you should try to avoid or at least minimize the use of these error- prone constructs. Dependability engineering 1, 2013 Slide 20
- 21. Error-prone constructs • Unconditional branch (goto) statements • Floating-point numbers – Inherently imprecise. The imprecision may lead to invalid comparisons. • Pointers – Pointers referring to the wrong memory areas can corrupt data. Aliasing can make programs difficult to understand and change. • Dynamic memory allocation – Run-time allocation can cause memory overflow. Dependability engineering 1, 2013 Slide 21
- 22. Error-prone constructs • Parallelism – Can result in subtle timing errors because of unforeseen interaction between parallel processes. • Recursion – Errors in recursion can cause memory overflow as the program stack fills up. • 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 the code. Dependability engineering 1, 2013 Slide 22
- 23. Error-prone constructs • 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. – This can cause problems if the default action is to transfer control elsewhere in the program. In incorrect or deliberately malicious input can then trigger a program failure. Dependability engineering 1, 2013 Slide 23
- 24. Provide restart capabilities • For systems that involve long transactions or user interactions, you should always provide a restart capability that allows the system to restart after failure without users having to redo everything that they have done. • Restart depends on the type of system – Keep copies of forms so that users don’t have to fill them in again if there is a problem – Save state periodically and restart from the saved state Dependability engineering 1, 2013 Slide 24
- 25. Check array bounds • In some programming languages, such as C, it is possible to address a memory location outside of the range allowed for in an array declaration. • This leads to the well-known ‘bounded buffer’ vulnerability where attackers write executable code into memory by deliberately writing beyond the top element in an array. • If your language does not include bound checking, you should therefore always check that an array access is within the bounds of the array. Dependability engineering 1, 2013 Slide 25
- 26. Include timeouts when calling external components • In a distributed system, failure of a remote computer can be ‘silent’ so that programs A expecting a service from that computer may never receive that service or any indication that there has been a failure. • To avoid this, you should always include timeouts on all calls to external components. • After a defined time period has elapsed B without a response, your system should then assume failure and take whatever actions are required to recover from this. Dependability engineering 1, 2013 Slide 26
- 27. Name all constants that represent real-world values Minimum_spee • Always give constants that reflect d real-world values (such as tax rates) names rather than using their numeric Error_rate values and always refer to them by name Max_daily_dos • You are less likely to make mistakes e and type the wrong value when you are using a name rather than a value. Tolerance • This means that when these VAT_rate ‘constants’ change (for sure, they are not really constant), then you only have to make the change in one place Dependability engineering 1, 2013 Slide 27 in your program.
- 28. Key points • Dependability in a program can be achieved by avoiding the introduction of faults, by detecting and removing faults before system deployment, and by including fault tolerance facilities. • The use of redundancy and diversity in hardware, software processes and software systems is essential for the development of dependable systems. • The use of a well-defined, repeatable process is essential if faults in a system are to be minimized. • Dependable programming relies on the inclusion of redundancy in a program to check the validity of inputs and the values of program variables. Dependability engineering 1, 2013 Slide 28