曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
the hazards and software inputs in each of the analyses (PHA, SSHA, SHA, and Operating & Support Hazard
Analysis (O&SHA)). Hazard causes can be identified as those caused by; hardware, and/or hardware
components; software inputs or lack of software input; human error; and/or software influenced human error
or hardware or human errors propagating through the software. Hazards may result from one specific cause
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-13
or any combination of causes. As an example, “loss of thrust” on an aircraft may have causal factors in any
of the four below listed categories.
· Hardware: foreign object ingestion,
· Software: software commands engine shutdown in the wrong operational scenario,
· Human error: pilot inadvertently commands engine shutdown, and,
· Software influence pilot error: computer provides incorrect information, insufficient or
incomplete data to the pilot causing the pilot to execute a shutdown.
The safety engineer must identify and define the hazard control considerations (PHA phase) and
requirements (SSHA, SHA, and O&SHA phases) for the design and development engineers. Hardware
causes are communicated to the appropriate hardware design engineers; and software related causes to the
software development and design team. All requirements should be reported to the systems engineering
group for their understanding and necessary tracking and/or disposition.
The preliminary software design SSHA begins upon the identification of the software subsystem and uses the
derived system specific safety-critical software requirements. The purpose is to analyze the system, software
architecture and preliminary CSCI design. At this point, all generic and functional Software Safety
Requirements (SSRs) should have been identified and it is time to begin allocating them to the identified
safety-critical functions and tracing them to the design.
The allocation of the SSRs to the identified hazards can be accomplished through the development of SSR
verification trees that links safety critical and safety significant SSRs to each Safety-Critical Function (SCF).
The SCFs in turn are already identified and linked to each hazard. By verifying the nodes through analysis,
(code/interface, logic, functional flow, algorithm and timing analysis) and/or testing (identification of
specific test procedures to verify the requirement), the Software Safety Engineer (SwSE) is essentially
verifying that the design requirements have been implemented successfully. The choice of analysis and/or
testing to verify the SSRs is up to the individual Safety Engineer whose decision is based on the criticality of
the requirement to the overall safety of the system and the nature of the SSR. Whenever possible, the Safety
Engineer should use testing for verification.
Numerous methods and analytical techniques are available to plan, identify, trace and track safety-critical
CSCIs and Computer Software Units (CSUs). Guidance material is available from the Institute of Electrical
and Electronic Engineering (IEEE) (Standard for Software Safety Plans), the Department of Defense (DOD)
Defense Standard 00-55-Annex B, DOD-STD-2167, NASA-STD-2100.91, MIL-STD-1629, the JSSSC
Software System Safety Handbook and DO-178B.
10.3.5 Testing
Two sets of analyses should be performed during the testing phase:
· Analyses before the fact to ensure validity of tests
· Analyses of the test results
Tests are devised to verify all safety requirements where testing has been selected as appropriate verification
method. This is not considered here as analysis. Analysis before the fact should, as a minimum, consider
test coverage for safety critical Must-Work-Functions.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-14
Test Coverage
For small pieces of code it is sometimes possible to achieve 100% test coverage (i.e., to exercise every
possible state and path of the code). However, it is often not possible to achieve 100 % test coverage due to
the enormous number of permutations of states in a computer program execution, versus the time it would
take to exercise all those possible states. Also there is often a large indeterminate number of environmental
variables, too many to completely simulate.
Some analysis is advisable to assess the optimum test coverage as part of the test planning process. There is
a body of theory that attempts to calculate the probability that a system with a certain failure probability will
pass a given number of tests.
“White box” testing can be performed at the modular level. Statistical methods such as Monte Carlo
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册上(11)
