曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
Component
Failures
1 X 10 -4
Likelihood
of Occurrence
Base Upon
Trained
Individuals
1 X 10 -3
Likelihood
of Occurrence
Base Upon
Software
Faults/Error
s ? X 10 -?
Figure 10-2: Likelihood of Occurrence Example
There have been numerous methods of determining the software’s influence on system-level risks. Two of
the most popular software listings are presented in MIL-STD 882C and RTCA DO-178B (see Figure 10-3).
These do not specifically determine software-caused risk probabilities, but instead assesses the software’s
“control capability” within the context of the software contributors . In doing so, each software contributors
can be labeled with a software control category for the purpose of helping to determine the degree of
autonomy that the software has on the hazardous event. The software safety team must review these lists and
tailor them to meet the objectives of the system safety and software development programs.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-9
(I) Software exercises autonomous control over potentially hazardous
hardware systems, subsystems or components without the possibility of
intervention to preclude the occurrence of a hazard. Failure of the software
or a failure to prevent an event leads directly to a hazards occurrence.
(IIa) Software exercises control over potentially hazardous hardware
systems, subsystems, or components allowing time for intervention by
independent safety systems to mitigate the hazard. However, these
systems by themselves are not considered adequate.
(IIb) Software item displays information requiring immediate operator
action to mitigate a hazard. Software failure will allow or fail to prevent
the hazard’ s occurrence.
(IIIa) Software items issues commands over potentially hazardous
hardware systems, subsystem, or components requiring human action to
complete the control function. There are several, redundant, independent
safety measures for each hazardous event.
(IIIb) Software generates information of a safety critical nature used to make
safety critical decisions. There are several, redundant, independent safety
measures for each hazardous event.
(IV) Software does not control safety critical hardware systems, subsystems,
or components and does not provide safety critical information.
MIL-STD 882C RTCA-DO-178B
(A) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure
of system function resulting in a catastrophic failure condition for
the aircraft.
(B) Software whose anomalous behavior, as shown by the System
Safety assessment process, would cause or contribure to a failure
of system function resulting in a hazardous/severe-major failure
condition of the aircraft.
(C) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure
of system function resulting in a major failure condition for the
the aircraft.
(D) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure of
system function resulting in a minor failure condition for the
aircraft.
(E) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure of
function with no effect on aircraft operational capability or pilot
workload. Once software has been confirmed as level E by the
certification authority, no further guidelines of this document apply.
Figure 10-3: Examples of Software Control Capabilities
Once again, the concept of labeling software contributors with control capabilities is foreign to most software
developers and programmers. They must be convinced that this activity has utility in the identification and
prioritization of software entities that possesses safety implication. In most instances, the software
development community desires the list to be as simplistic and short as possible. The most important aspect
of the activity must not be lost, that is, the ability to categorize software causal factors for the determining of
both risk likelihood, and the design, code, and test activities required to mitigate the potential software cause.
Autonomous software with functional links to catastrophic risks demand more coverage than software that
influences low-severity risks.
Software Hazard Criticality Matrix
The Software Hazard Criticality Matrix (SHCM) (see Figure 10-4 for an example matrix) assists the software
safety engineering team and the subsystem and system designers in allocating the software safety
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册上(8)
