InjectingFaultsforErrorEvaluation.pptVIP

SAS 2004 - Fault Injection Injecting Faults for Error Evaluation NASA Glenn Research Center Kalynnda Berens, SAIC Richard Plastow, SAIC Introduction Applications often consists of software components plus custom development, merged into a coherent package. COTS, GOTS, open source, etc. Source code is usually not available for review of quality and reliability. Visibility into the component is only what’s available via a public interface What is the quality of that component? What faults lay inside the component? Applications interface with hardware and other software and can be influenced by failures in those systems. Fault Injection on Interfaces Interfaces (hardware, software, human) are a major source of errors and induced faults Software and system testing looks at anticipated off-nominal situations, but often misses unusual situations or combinations of faults Mishap investigation has shown that multiple faults or unexpected anomalies are key players in accidents and mission failures Example System Fault Injection Flow Diagram Interface Identification Artifacts and Documentation Software and System Requirements and Design specifications Interface Specifications User and Training Manuals Hardware Documentation Other project documentation For FCF, “Signals List” Source code Error Research Sources of Error/Fault Information Vendor documentation Public bug list Internet Sources Software logs Error databases Project Experience Previous Test Results Personnel Experience Estimation of Effort Determine level of effort, funding, time constraints If complete effort not possible Perform importance analysis of interfaces, software units Safety Complexity Use by other system elements Expected number or types of faults Prioritize and select by importance Testing Test case generation based on identified errors plus permutations on possible input values Consider multiple faults Consider faults while system is off-nominal from a previous fault Consider effects of system loa