Software Faults and Fault Injection Models

1. Software Faults and Fault Injection Models --Raviteja Varanasi

2. Overview • Introduction • Fault Tolerance • Taxonomy Of Faults • Software Fault Injection Models • Conclusion

3. INTRODUCTION Major Approaches for studying fault Impacts • Analytical Modeling • Field Error Data Analysis • Fault Simulation • Fault Injection

4. Software Fault Tolerance • By software fault tolerance we mean a set of application level software components that can detect and recover from faults that are not handled in the hardware/operating system. • A failure occurs when the system deviates from its specifications. The cause of a failure is an error. A fault has the potential for generating errors i.e. it may/may not generate any errors. A system with errors will be faulty.

5. Why do we need it? • Because many systems today are expected to work in a correct manner as life depends on them. • Cost of errors to high. • Testing is not suitable measure of reliability. • Can only establish the presence of errors but cannot assure their absence. • relies heavily on manual skills to identify test cases and evaluate results

6. Taxonomy of Faults • Physical Faults • Design Faults • Interaction Faults

7. Physical Faults • Hardware Faults • Memory Faults • CPU Faults • Bus Faults • I/O Faults

8. Design Faults • Software Faults • Initialization Faults • Assignment Faults • Condition check Faults • Function Faults • Documentation Faults

9. Taxonomy of Faults FAULTS Physical Faults Design Faults Interaction Faults • Hardware Faults • Memory Faults • CPU Faults • Bus Faults • I/O Faults • Software Faults • Initialization Faults • Assignment Faults • Condition Check Faults • Function Faults • Documentation Faults Faults Induced by the User

10. Software Fault Injection • A testing technique that aids in understanding how software behaves when stressed in unusual ways. • A product-based assurance technique. • Variations in the technique allow it to be applied to many types of software and for different purposes.

11. Software Fault Injection • Software Fault Injection Models • DIDUCE (Dynamic Invariant Detection U Checking Engine) • FINE (A Fault Injection and Monitoring Environment for tracing the UNIX System Behavior under Faults

12. DIDUCE • A General Purpose error detector which works on Java Byte Code • Detects Invariants Dynamically • Detects Errors Dynamically • A very useful Debugging Tool

13. DIDUCE (Dynamic Invariant Detection U Checking Engine) • Instruments the Code (Java Byte Code) • Watches the Data (E.g. Parameters,values read) • Develops a model of the data (Keeps a 2-word Signature per tracked value) • Reports detected anomalies • Relaxes Properties and continues • Finds Hidden Errors • Automatically Detects root causes of Errors

14. DIDUCE • A Large Program works on many but fails on just 1 • A change to a component causes another component in a large system to fail • Failures in long Running Programs

15. FINE: A Fault Injection and Monitoring Environment • A fault Injection tool for monitoring the study of fault propagation in UNIX kernel • Injects both Hardware induced software errors and software faults and traces execution • A comparison is then made between the faulty trace data and the fault free one under the same work load to identify fault propagation

16. FINE: How it works • Consists Mainly of Four Parts • Fault Injector : Injects hardware and software faults • Software Monitor: traces the execution flow • Workload Generator: generates the workload • Controller: specifies fault type to the Fault Injector, the data to Software monitor and workload for Workload generator

17. Conclusion • Exploration of fault behaviors on a complex program is tedious • But this exploration is necessary to understand the complex mechanisms of error propagation • Faults depend heavily on the application and the specific functional unit where they appear

18. References [1] J. Dures and H. Madeira, “Characterization of Operating Systems Behavior in the Presence of Faulty Drivers Through Software Fault Emulation,” PRDC2002 Pacific Rim International Symposium on Dependable Computing, pp. 16–18, December 2002. [2] H. Madeira, M. Vieira, and D. Costa, “On the Emulation of Software Faults by Software Fault Injection,” IEEE International Conference on Dependable Systems and Networks, pp. 25–28, June 2000. [3] J. Arlat, Y. Crouzet, and J. Karlsson, “Comparison of Physical and Software- Implemented Fault Injection Techniques,” IEEE Transactions on Computers, pp. 1115–1133, September 2003. [4] M. Hsueh, T.Tsai, and R.K.Iyer, “Fault Injection Techniques and Tools,” IEEE Transactions on Computers., pp. 75–82, April 1997. [5] R. Chillarege, I.S.Bhandari, J.K.Chaar, M.J.Halliday, D.Moebus, B.Ray, and M.Wong, “Orthogonal Defect Classification - A Concept for In-Process Measurement,” IEEE Transactions on Software Engineering, pp. 943–956, November 1992. [6] W. Kao, R.K.Iyer, and D.Tang, “FINE: A Fault Injection and Monitoring Environment for Tracing the UNIX system Behavior Under Faults,” IEEE Transactions on Software Engineering., pp. 1105–1118, November 1993.

19. References • [7] J. Carreira, H. Madeira, and J. G. Silva, “Xception: A Technique for the Experimental Evaluation of Dependability in Modern Computers,” IEEE Transactions on Software Engineering, pp. 125–136, February 1998. • [8] D. Costa, M. V. Tiago Rilho, and H. Madeira, “ ESFFI - A Novel Technique for the Emulation of Coftware Faults in COTS Components ,” IEEEEighth Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS ’01), pp. 197–204, April 2001. • [9] T. Jarboui, J. Arlat, Y. Crouzet, and K. Kanoun, “ Experimental Analysis of the Errors Induced into Linux by Three Fault Injection Techniques ,” DSN’02International Conference on Dependable Systems and Networks, pp. 23–26, June 2002. • [10] N. S. Bowen and D. K. Pradhan, “ The Effect of Program Behaviour on Fault Observability,” IEEETransactions on Computers, pp. 868–880, Aug 1996. • [11] A. Johansson, “Software Implemented Fault Injection Used for Software Evaluation ,” Predicting System Trustworthiness for Software Component Trustworthiness, pp.38–43, July 2002. • [12] S. Hangal and M.S.Lam “ Tracking down software bugs using automatic anomaly detection.” International Conference on Software Engineering, pp 291-301, May-2002

20. Thank You