Date: Tue, 10 Dec 1996 03:34:55 GMT Server: NCSA/1.4.2 Content-type: text/html Software Safety (UW) -- Research

Software Safety at the University of Washington


Our research is currently centered on building a CAD environment for safety-critical software. The development environment contains a set of support and analysis tools that work on system and software specifications written in a language that we believe will support communication among the various development groups, including system engineers, software engineers, application experts, and human factors (cognitive) engineers.

The specification language, RSML (Requirements State Machine Language), has a formal foundation and is suitable for automated analysis, but we have also found it to be readable by application experts with little training and minimal mathematical background. One unique aspect of our approach is that the analysis is performed directly on the system specification. Most approaches to formally evaluating systems require the extra and often difficult step of translating the system design into a mathematical modeling language. Our executable model/specification is the system specification, and the identified hazards and their control requirements are traceable (in both directions) from the early preliminary hazard identification through to design and implementation. As the system development proceeds, analyses and evaluations can be performed that are appropriate to the particular development stage. For more information, see the original RSML paper, Requirements Specification for Process-Control Systems. A paper on the updates to RSML is in preparation.

RSML was originally developed to specify the system requirements for TCAS II (an aircraft collision avoidance system). Since that first demonstration of our approach to a real system, we have been extending the modeling language to include intent and design rationale, improving the readability and usability of the models, and developing a suite of automated tools to assist in evaluating the model/specification for safety. The major changes to RSML are being made to assist in dealing with the complexity of real systems. Because understanding the specification is crucial for human detection of errors, we are also experimenting with various types of visualization techniques to assist the analyst in understanding the model and the analysis results.

Our approach to safety evaluation is based on system safety engineering concepts. We use standard safety engineering approaches and extend them to deal with software and human error, and we use automation to enhance our ability to cope with complex systems. Identification, classification, and evaluation of hazards is done using modeling and analysis. To be effective, these models and analysis tools must consider hardware, software, and human components. They also need to include a variety of analysis techniques and orthogonal approaches: There exists no single safety analysis or evaluation technique that can handle all the aspects of complex systems. The safety analysis tools we currently are prototyping and evaluating include:

  • Simulator. RSML specifications can be executed using analyst-supplied scenarios or test cases. The simulator is operational but we have a few limitations on the language that we need to relax.
  • Backward Simulation and Fault Tree generation. Backward simulation starts at a particular system configuration and identifies the paths that could have led to that configuration. Starting with a particular hazard, the analyst can use backward simulation to determine whether this hazard could occur and how. Information about the states preceding a hazard can be used to eliminate the hazard from the design. The results of this backward analysis can be presented in the form of a fault tree.
  • Consistency and Completeness Checking. This tool checks RSML specifications for two properties: (1) completeness with respect to a set of criteria related to robustness (a response is specified for every possible input and input sequence) and (2) consistency (the specification is free from conflicting requirements and undesired nondeterminism). The method scales up to large systems by decomposing the specification into smaller, analyzable parts and then using functional composition rules to ensure that verified properties hold for the entire specification. The tool has been used on the TCAS specification and others. For more information, see our paper titled Completeness and Consistency Analysis of State-Based Requirements.
  • Deviation Analysis. Deviation Analysis is a new safety analysis technique to aid in identifying specified behavior that may lead to hazardous system states. The procedure is based on the underlying systems theory that accidents are caused by deviations in system paramenters. Using a formal software or system requirements specification, the analyst provides assumptions about particular deviations in software inputs and the procedure automatically generates the scenarios in which the analyst's assumptions lead to deviations in identified safety-critical outputs. Software Deviation Analysis incorporates many of the beneficial features of HAZOP but automates this manual hazard analysis technique and extends it to handle the complexity and logical nature of computer software.
  • Deviation Analysis Interface A GUI to aid in the use of software deviation anlaysis.
  • Human-Computer Interface Safety Analysis. These tools are still under development, but our goal is to extend RSML to include the human-computer interface and to apply hazard analysis techniques to this augmented model.
  • Timing Analysis. With Professor Alan Shaw, we are exmining how to add timing analysis tools to our toolset.

A screen snapshot of the requirements engineering environment.

The requirements engineering environment supports or will support:

  • A graphical user interface for creating, editing, and browsing specifications.
  • Graphical and textual interfaces to each of the analysis methods listed above. This affords interactive exploration as well as automated batch processing.
  • Both graphical and textual specification representations.
  • A pretty printer that produces printed specifications.
In addition to TCAS II, we have several other realistic test beds for our analyses and toolkit. These include an model of an automated highway system from the UCB PATH project, an aircraft flight guidance system from NASA Ames, and a NASA robot.

Planned:

  • Human-computer interface analysis.

  • Improved and new hazard analysis techniques.

  • Testing tools.

  • More completeness analyses.

  • Timing analysis.

  • Improved modeling language.

  • Demonstration on part of the U.S. air traffic control system.