曝光臺(tái) 注意防騙 網(wǎng)曝天貓店富美金盛家居專營(yíng)店坑蒙拐騙欺詐消費(fèi)者

functional areas having an unacceptable risk potential. Risk assessment and the use of a Hazard Risk
Index (HRI) Matrix as a standardized means with which to group hazards by risk are described in
Attachment 2, Sections 6.1 & 6.2 of draft AC 431.35-2. This section presents specialized methods of
analyzing hazards, which possess software influence or causal factors and supplements the HRI presented
in draft AC 431.35-2.
The Hazard Risk Index presented in draft AC 431.35-2 is predicated on the probability of hazard
occurrence and the ability to obtain component reliability information from engineering sources.
Hardware reliability modeling of a system is well established; however, there is no uniform, accurate or
practical approach to predicting and measuring the software reliability portion of the system. Since
software does not fail in the same manner as hardware, in that it is not a physical entity, it does not wear
out, break, or degrade over time; software problems are referred to as a software error. Software errors
general occur due to implementation or human failure mechanisms (such as documentation errors, coding
errors, incorrect interpretation of design requirements, specification oversight, etc.) or requirement errors
(failure to anticipate a set of conditions that lead to a hazard). Unlike hardware, software has many more
failure paths than hardware, making it difficult to test all paths. Thus the ultimate goal of software system
safety is to find and eliminate the built-in unintended and undesired hazardous functions driven by
software in a CST system.
Classification of Software Safety Risk
There are two basic steps in classifying safety risk for software. The first being the establishment of
severity within the context of the CST system and then applying an acceptable methodology for
determining the software’s influence on system level risks. Refer to Figures 13-4 and 13-5. Regardless of
the contributory factors (hardware, software, or human error) the severity of risk as present in draft AC
431.35-2 Attachment 2, Section 6.1.2, Figure 6.1.2, remain applicable criteria for the determination of
hazard criticality for those risks possessing software contributory factors.
The second half of the equation for the classification of risk is applying an acceptable methodology for
determining the software’s influence on system level hazards. The probability factors contained in draft
AC 431.35-2 has been determined for hardware based upon historical “best” practices. Data for the
assignment of accurate probabilities to software error has not matured. Thus alternate methods for
determining probability propagated by software causal factors need to be used. Numerous methods of
determining software effects on hardware have been developed and two of the most commonly used are
presented in MIL-STD 882C and RTCA DO-178 and are shown in Figure 4. These methods address the
software’s “control capability” within the context of the software casual factors. An applicant Software
System Safety Team should review these lists and tailor them to meet the objectives of their CST system
and integrated software development program.
This activity of categorizing software causal factors is for determining both likelihood, and the design,
coding, and test activities required to mitigate the potential software contributor. A Software Hazard
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
23
Criticality (SHC) Matrix, similar to the hazard risk index (HRI)6 matrix is used to determine the
acceptability of risk for software hazards. Figure 3 shows an example of a typical SHC matrix using the
control categories of MIL-STD 882C [Mil882C]. The SHC matrix can assist the software system safety
team in allocating software safety requirements against resources and in the prioritization of software
design and programming tasks.
Software Hazard Analysis/Risk Mitigation
Fault tree analysis (FTA) may be used to trace system-specific software safety-critical functional
hazards7. The hazard software causal factor nodes are then traced to the appropriate mitigating CST
System Requirement, design segment, and coding segment. The hazard should be tracked through the test
procedure development; to assure the test procedures have been written sufficiently to demonstrate the
hazard is adequately controlled (mitigated).
Software Safety Analysis Methods and Tools8
The following is not intended to be an all-inclusive or exhaustive list of software safety analysis methods
and tools; nor does it represent an explicit or implicit AST recommendation thereof.
6 See Attachment 2, Section 6.2 of AC 431.35-2 for discussion and illustration of HRI.
　
中國(guó)航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊(cè)上(42)