曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
influence the design of the system to ensure that it is safe when it enters the production phase of the
acquisition life cycle. This can be accomplished effectively if the following process tasks are performed:
· Identify the safety critical functions of the system.
· Identify the system and subsystem hazards/risks.
· Determine the effects of the risk occurrence.
· Analyze the risk to determine all contributing factors (i.e.. hardware, software, human
error, and combinations of each.)
· Categorize the risk in terms of severity and likelihood of occurrence.
· Determine requirements for each contributing factor to eliminate, mitigate, and/or
control the risk to acceptable levels. Employ the safety order of design precedence
Chapter 3, Table 3-7, for hazard control.
· Determine testing requirements to prove the successful implementation of design
requirements where the hazard risk index warrants.
· Determine and communicate residual safety risk after all other safety efforts are
complete to the design team and program management.
10.2 The Importance of System Safety
Before an engineer (safety, software, or systems) can logically address the safety requirements for software,
a basic understanding of how software “fails” is necessary. Although the following list may not completely
address every scenario, it provides the most common failure mechanisms that should be evaluated during the
safety analysis process.
· Failure of the software to perform a required function, i.e., either the function is never
executed or no answer is produced.
· The software performs a function that is not required, i.e., getting the wrong answer,
issuing the wrong control instruction, or doing the right action but under inappropriate
conditions.
· The software possesses timing and/or sequencing problems, i.e., failing to ensure that
two things happen at the same time, at different times, or in a particular order.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-4
· The software failed to recognize that a hazardous condition occurred requiring corrective
action.
· The software failed to recognize a safety-critical function and failed to initiate the
appropriate fault tolerant response.
· The software produced the intended but inappropriate response to a hazardous condition.
· The specific causes most commonly associated with the software failure mechanisms
listed above are:
· Specification Errors: Specification errors include omitted, improperly stated,
misunderstood, and/or incorrect specifications and requirements. Software may be
developed "correctly" with regard to the specification, but wrong from a systems
perspective. This is probably the single largest cause of software failures and/or errors.
· Design and Coding Errors: These errors are usually introduced by the programmer and
can result from specification errors, usually the direct result of poor structured
programming techniques. These errors can consist of incomplete interfaces, timing
errors, incorrect interfaces, incorrect algorithms, logic errors, lack of self-tests, overload
faults, endless loops, and syntax errors. This is especially true for fault tolerant
algorithms and parameters.
· Hardware/Computer Induced Errors: Although not as common as other errors, then can
exist. Possibilities include random power supply transients, computer functions that
transform one or more bits in a computer word that unintentionally change the meaning
of the software instruction, and hardware failure modes that are not identified and/or
corrected by the software to revert the system to a safe state.
· Documentation Errors: Poor documentation can be the cause of software errors through
miscommunication. Miscommunication can introduce the software errors mentioned
above. This includes inaccurate documentation pertaining to system specifications,
design requirements, test requirements, source code and software architecture documents
including data flow and functional flow diagrams.
· Debugging/Software Change Induced Hazards: These errors are basically selfexplanatory.
The cause of these errors can be traced back to programming and coding
errors, poor structured programming techniques, poor documentation, and poor
specification requirements. Software change induced errors help validate the necessity
for software configuration.
FAA System Safety Handbook, Chapter 10: System Software Safety
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册上(5)
