曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

10.4 SYSTEM SAFETY ASSESSMENT REPORT (SSAR) .................................................................14
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-2
10.0 SYSTEM SOFTWARE SAFETY
10.1 Introduction
Much of the information in this chapter has been extracted from the JSSSC Software System Safety
Handbook, December, 1999, and concepts from DO-178B, Software Considerations in Airborne Systems
and Equipment Certification, December 1, 1992.
Since the introduction of the digital computer, system safety practitioners have been concerned with the
implications of computers performing safety-critical or safety-significant functions. In earlier years, software
engineers and programmers constrained software from performing in high risk or hazardous operations
where human intervention was deemed both essential and prudent from a safety perspective. Today,
however, computers often autonomously control safety critical functions and operations. This is due
primarily to the capability of computers to perform at speeds unmatched by its human operator counterpart.
The logic of the software also allows for decisions to be implemented unemotionally and precisely. In fact,
some current operations no longer include a human operator.
Software that controls safety-critical functions introduce risks that must be thoroughly addressed (assessed
and mitigated?) during the program by both management and design , software , and system safety
engineering. In previous years, much has been written pertaining to "Software Safety" and the problems
faced by the engineering community. However, little guidance was provided to the safety practitioner that
was logical, practical, or economical. This chapter introduces an approach with engineering evidence that
software can be analyzed within the context of both the systems and system safety engineering principles.
The approach ensures that the safety risk associated with software performing safety-significant functions is
identified, documented, and mitigated while supporting design-engineering objectives along the critical path
of the system acquisition life cycle.
The concepts of risk associated with software performing safety-critical functions were introduced in the
1970's. At that time, the safety community believed that traditional safety engineering methods and
techniques were no longer appropriate for software safety engineering analysis. This put most safety
engineers in the position of “wait and see.” Useful tools, techniques, and methods for safety risk
management were not available in the 1970's even though software was becoming more prevalent in system
designs.
In the following two decades, it became clear that traditional safety engineering methods were indeed
partially effective in performing software safety analysis by employing traditional approaches to the
problem. This situation does not imply, however, that some modified techniques are not warranted. Several
facts must be realized before a specific software safety approach is introduced. These basic facts must be
considered by the design engineering community to successfully implement a system safety methodology
that addresses the software implications.
·  Software safety is a systems issue, not a software-specific issue. The hazards caused by
software must be analyzed and solved within the context of good systems engineering
principles.
·  An isolated safety engineer may not be able to produce effective solutions to potential
software-caused hazardous conditions without the assistance of supplemental expertise.
The software safety "team" should consist of the safety engineer, software engineer,
system engineer, software quality engineer, appropriate "ility" engineers (configuration
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-3
management, test & evaluation, verification & validation, reliability, and human
factors), and the subsystem domain engineer.
·  Today's system-level hazards, in most instances, contain multiple contributing factors
from hardware, software, human error, and/or combinations of each, and,
·  Finally, software safety engineering cannot be performed effectively outside the
umbrella of the total system safety engineering effort. There must be an identified link
between software faults, conditions, contributing factors, specific hazards and/or
hazardous conditions of the system.
The safety engineer must also never lose sight of the basic, fundamental concepts of system safety
engineering. The product of the system safety effort is not to produce a hazard analysis report, but to
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊上(4)