An introductory tutorial on software safety will be provided at the beginning of the summer program. A series of training seminars will also be organized to help less experienced students establish necessary background knowledge and improve their technical and research skills before working on assigned research projects. Additional seminars by experts from Raytheon Network Centric Systems, Lockheed Martin Aeronautics Company, and EDS, an HP Company will be scheduled as well to help the students better understand how software safety is verified and validated in practice for real-life applications. Follow-up meetings will be organized for students to discuss with invited speakers how to address the gap between the current "state-of-practice" and "state-of-art" with respect to software safety.
Listed below are the descriptions of a few sample projects.
1) Impact of Software Safety on Software Lifecycle
This project investigates how the introduction of software safety requirements may affect the software development lifecycle, and answer questions such as
In particular, the effort will be spent on
Results from these studies can help us understand whether safe software will cost more to produce and whether safety-critical software has to be more complex than software with less stringent safety requirements. Our previous study discussed the use of various safety standards in producing safe software, and examined the factors which help projects produce software with high safety requirements at reduced cost. It also analyzed the reasons why other projects spent more money due to the requirements of software safety. Our findings suggest that 1) it is possible to develop software, despite significant and stringent safety requirements, without sacrificing cost effectiveness, and 2) projects can realize savings by using mature processes and appropriate tools to assist in development and testing.
REU students are expected to extend the above study to additional projects and safety standards. They will explore the cost-effectiveness between the degree of required software safety and the development cost.
2) Evaluation of Software Safety Standards
To build software systems with high safety requirements, it is important to approach the process in a certain way to maintain efficiency and ensure with a high degree of confidence that the requirements are met effectively. Software safety standards are commonly used to closely guide the development of such systems. However, given the existence of multiple competing safety standards, it is critical to select the one that is most appropriate for a given project. We have developed a set of 15 criteria to evaluate each standard in terms of usage, strengths and limitations.
REU students are expected to contribute in the following ways:
3) An Integrated Approach for Improved Software Safety Analysis
The analysis of software safety today is not based on an integrated model considering both functional and safety specifications simultaneously. As a result, it does not give a thorough analysis of all possible failures. The objective of this research is to integrate safety analysis methods with functional requirements to reduce failures inherent in performing the two independently.
We propose to use Fault Tree Analysis (FTA), which has been widely used as a way to analyze causes of hazards, and the UML state machine, the de facto standard for representing the functional specifications of a software system.
REU students are expected to contribute in the following ways:
4) Testing for Software Safety
Testing for consistency between implementation and functional specifications does not provide safety assurance. It is difficult to generate tests for safety testing by only using the hazard analysis results presented in the fault tree models, because of the lack of an explicit and common description of the relationship between a fault tree and the corresponding functional specifications and safety requirements.
Our research objectives are twofold: to integrate functional specifications with fault tree models for testable safety analysis and to generate safety tests from the integrated specifications. The first objective allows potential components and system failures to be specified explicitly together with the intended behaviors of a system. The second objective aims at detection of potential failures through systematic safety-driven testing. We note that this research focuses on testing whether or not the hazardous conditions identified by design-level fault tree analysis will occur in the target implementation. Functional specifications often focus on intended behaviors of a system and are intrinsically incomplete. If complete interactions between hazardous conditions and intended behaviors are specified, they can be used to generate safety tests. Research along this line remains to be seen, however, due to the heterogeneity of functional specifications and fault models (e.g., statecharts versus fault trees). A critical problem is that some basic events in a fault tree may have no counterpart in the corresponding functional specifications.
The approach consists of three major parts:
5) An enhanced study of the culpability of software in recent catastrophic accidents
Studies conducted from our previous summer programs have suggested that an error in software or an error in its use can cause catastrophic accidents resulting in severe consequences.
One example of accidents which caused human casualty was the crash of American Airlines Flight 965 in 1995 with 159 deaths. If the pilot enters an initial instead of the full name of the destination, the flight management system selects the destination which has the highest usage frequency among all the destinations starting with that initial. Since the system did not provide any feedback once the destination had been selected, a course was set to an incorrect airport and caused the crash.
We will extend our study to include a more recent cross-section of accidents drawn from aeronautics, astronautics, medicine, nuclear power generation, transportation, finance, military, etc. The emphasis is on a cross comparison between various software-related accidents to derive common lessons that could be learned as well as the context of each lesson and the circumstances under which they are applicable. Such information can be used to help prevent future accidents.