
|
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.


|