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

SUBSYSTEM (SSHA) & SYSTEM (SHA) HAZARD ANALYSIS
Tracing Safety-Critical Requirements to Test
ð Tag Safety-Critical Software Requirements
ð Establish Methods for Tracing Software Safety Requirements to Test
ð Provide Evidence for Each Functional Hazard Mitigated by Comparing to Requirements
ð Implement Software Safety Requirements into Design and Code
ð Provide Evidence of Each Functional Hazard Mitigated by Comparing to Design
ð Verify Safety Requirement Implementation Through Test
ð Execute Residual Risk Assessment
ð Verify Software Developed in Accordance with Applicable Standards and Criteria
SOFTWARE SAFETY ASSESSMENT REPORT (SAR)
Software Requirements Derivation for
Safety-Critical Software Systems
Figure 10-5: Software Safety Requirements Derivation
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-12
Preliminary Software Safety Requirements
The first “cut” at system-specific software safety requirements are derived from the PHA analyses performed
in the early life cycle phase of the development program. As previously discussed, the PHL/PHA hazards
are a product of the information reviewed pertaining to systems specifications, lessons learned, analyses from
similar systems, common sense, and preliminary design activities. Hazards that are identified during the
PHA phase are analyzed and preliminary design considerations are identified to design engineering to
mitigate the risk. These design considerations represent the preliminary safety requirements of the system,
subsystems, and their interfaces (if known). These preliminary requirements must be accurately defined in
the hazard record database for extraction when reporting of requirements to the design engineering team.
Matured Software Safety Requirements
As the system and subsystem design mature, the requirements unique to each subsystem also matures via the
Subsystem Hazard Analysis (SSHA). The safety engineer, during this life cycle phase of the program,
attends the necessary design reviews and spends many hours with the subsystem designers for the purpose of
accurately defining the subsystem hazards. Hazards/risks identified are documented in the hazard database
and the hazard “causes” (hardware, software, human error, and software-influenced human error) identified
and analyzed. When fault trees are used as the functional hazard analysis methodology, the contributors
leading to the risk determine the derived safety-critical functional requirements. It is at this point in the
design that preliminary design considerations are either formalized and defined into specific requirements, or
eliminated if they no longer apply with the current design concepts. The maturation of safety requirements is
accomplished by analyzing the design architecture to connect the risk to the contributors. The causal factors
are analyzed to the lowest level necessary for ease of mitigation. The lower into the design the analysis
progresses, the more simplistic (usually) and cost effective the mitigation requirements tend to become. The
PHA phase of the program should define causes to at least the Computer Software Configuration Item
(CSCI) level, whereas the SSHA and System Hazard Analysis (SHA) phases of safety analyses should
analyze the causes to the algorithm level where appropriate.
10.3.4 Design and Analyses
The identification of subsystem and system hazards and failure modes inherent in the system under
developed is essential to the success of a credible software safety program. The primary method of reducing
the safety risk of software performing safety-significant functions is to first identify the system hazards and
failure modes, and then determine which hazards and failure modes are caused by or influenced by software
or lack of software. This determination includes scenarios where information produced by software could
potentially influence the operator into a wrong decision resulting in a hazardous condition (design-induced
human error). Moving from hazards to software contributors (and consequently design requirements to
either eliminate or control the risk) is very practical, logical, and adds utility to the software development
process. It can also be performed in a timelier manner as much of the analysis is accomplished to influence
preliminary design activities.
The specifics of how to perform either a subsystem or system hazard analysis are briefly described in
Chapters 8 and 9. The fundamental basis and foundation of a system safety (or software safety) program is a
systematic and complete hazard analysis process.
One of the most helpful steps within a credible software safety program is to categorize the specific causes of
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊上(10)