An Assessment of Space Shuttle Flight Software Development Processes (1993) / Chapter Skim
Currently Skimming:
5. The Silent Safety Program Revisited
5. The Silent Safety Program Revisited
Pages 61-76
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 61... ...
are identified before accidents occur and then elim~na~ or controlled to an acceptable level. NASA was the first group outside of He military to adopt system-safety engineering and, spurred on by the Apollo fire in 1967, established one of the best system-safety programs of the time.
|
From page 62... ...
, politics, and budget cuts. The Rogers Commission reports on Be Challenger accident identified many safety engineering and management problems at NASA and speaks of a Silent Safety Program that had, for some reason, lost at least some of its effectiveness after the Apollo flights.
|
From page 63... ...
The inherent risk of the Space Shuttle program is defined by the combination of a highly dynamic environment' enormous energies, mechanical complexities, timeconsuming preparations and extremely hme-cntical decision making. Complacency and failures in supervision and reporting seriously aggravate these risks.
|
From page 64... ...
This is an enticing approach since it is theoretically possible compared with the impossibility of eliminating wear-out failures in hardware devices. Marty people have realized, however, that, although perfect software could be constructed ~eoredc~ly, it is impossible from a practical standpoint to build complex software that watt behave exactly as it should under all conditions, no matter what changes occur in He other components of the system (including failures)
|
From page 65... ...
NASA, in the Shuttle software, has emphasized the first two approaches, although early development efforts did attempt to include the software in the system-safety design efforts and especially to evaluate the requirements from a system-safety viewpoint. For example, in 1979 TRW performed a software hazard analysis that identified 38 potentially hazardous software behaviors.
|
From page 66... ...
in auoltlon, several SpeClilC software Hugo analysis tasks are 1dendned: ~ Software Requirements Hazard Analysis: The purpose of the Software Requirements Hazard Analysis is to (~) identify required and recommended actions to eliminate identified hazards or reduce their associated risk to an acceptable level and (2)
|
From page 67... ...
The Committee understands that there is a good chance the NASA draft software safety guideline may be approved soon. However, even ~en,~-it will be possible for the venous centers and programs to tailor their software safety programs without approval from those responsible for safety at headquarters.
|
From page 68... ...
The first step in any software safety program is the generation of a baseline hazard analysis that identifies potential hazardous behavior of the software that could contribute to system hoards. The Committee independently discovered Hat TRW was under contract in 1979 to do a Software Hazard Analysis for the Shuttle.
|
From page 69... ...
By doing a SoftwareChange Hazard Analysis based on the information contained in the baseline hazard analysis, redundant effort win be eliminated and, more important, the chance for errors will be reduced, and the oversight ability of the NASA S&MQ staff win be enhanced. Communication and traceability must also proceed in the other direction, from the software change activities to the system-safety activity.
|
From page 70... ...
MSFC answered Hat Hey sent Safety Assessment and Hazard Analysis Reports to He higher levels, but did not describe how often or how thoroughly Hey are used. Furthermore, the Commode found evidence Hat not all detected errors or hazards in the software are reviewed by the SASCB.
|
From page 71... ...
interfaces associated with the conduct of the Shuttle software safety program. Recommendation #8: NASA should perform a hazard analysis for the Shuttle software, as described in the draft software safety guideline.
|
From page 72... ...
At ISC, there is one civil service employee and four contractors to support the flight software activities in the Safety Division of SR&QA. The same number support the Reliability Division, and the Quality Division has the equivalent of one and one half Civil Service employees and four and one half support contractors.
|
From page 73... ...
The responsibilities of this office should include: · the SR&QA functions as Key relate to an NASA activities and programs; and · direction of reporting and documentation of problems, problem resolution, and trends associated with flight safety. The relationship between the safety office at each center and the safety efforts within the development contractors appears also to be nonexistent or indirect (i.e., through the SASCB)
|
From page 74... ...
offices is undefined and ambiguous in practice and appears to contradict the original recommendation of the Rogers Commission for establishing these offices.
|
From page 75... ...
This board reviews system-safety and software-safety analyses that include: idendficabon of hazards; identification of causal links to software; identification of safety-cn~cical computer software components and units; development of safety design requirements; identification of generic safety design requirements from generic documents and lessons learned; tracing of safety design requirements; identification and analysis of critical source code and methodology chosen; results of detailed safety analyses of critical functions; analysis of design-change recommendations for potential safety impacts; and final assessment of safety issues. The Weapons Review Board is supported in these tasks by a Software Systems Safety Technical Review Board.
|
From page 76... ...
Recom~nendation #11: NASA should consider the establishment of a NASA safety certification panel or board separate from the program offices arm also the establishment of a subcommittee of the Aerospace Safety Advisory Panel to deal with software issues.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.