曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
general model for preparing software safety documents
The results of most of the safety analyses activities usually require preparing several hazard analysis
reports documenting the findings of the safety team. The team has also the responsibility of presenting
their findings to decision-making management at critical milestones, like the Software Requirements
Review (SRR), Preliminary Design Review (SDR), Critical Design Review (CDR), etc. Towards this end,
DOD Defense Standard 00-55-Annex E describes how to prepare a software safety “case”. The Standard
defines a case as “a well-organized and reasoned justification, based on objective evidence, that the
software does or will satisfy the safety aspects of the Software Requirement”.
13.5.3 Software Safety Documentation
Numerous documents are to be prepared and distributed during the SSSP. To track them, a
comprehensive checklist, such as that cited in MIL STD 882 may be applied. Two highly recommended
documents are the Safety Assessment Report (SAR) and the System Safety Hazard Analysis Report
(SSHA). DOD Defense Standard 00-55-Annex B offers a detailed outline of the contents of numerous
software safety documents (software safety plan, case or report, records log, audit plan, audit report,
quality plan, risk management plan, verification/validation plan, etc.) Annex B should serve as a general
model for preparing software safety documents. The results of most of the safety analyses activities
usually require preparing several hazard analysis reports documenting the findings of the safety team.
The team also has the responsibility of presenting their findings to decision-making management at
critical milestones, like the Software Requirements Review (SRR), Preliminary Design Review (SDR),
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
21
Critical Design Review (CDR), etc. Towards this end, DOD Defense Standard 00-55-Annex E describes
how to prepare a software safety “case”. The Standard defines a case as “a well-organized and reasoned
justification, based on objective evidence, that the software does or will satisfy the safety aspects of the
Software Requirement”.
13.5.4 Safety Critical Software functions
Software can be labeled defective if it does not perform as expected. Major classes of defects are:
· Software not executing
· Software executing too late, too early, suddenly or out of sequence, or
· Software executing but producing wrong information.
In turn, defective software can be labeled hazardous if it consists of safety-critical functions that
command, control and monitor sensitive CST systems. Some typical software functions considered
safety-critical include:
· Ignition Control: any function that controls or directly influences the pre-arming, arming,
release, launch, or detonation of a CST launch system.
· Flight Control: any function that determines, controls, or directs the instantaneous flight path
of a CST vehicle.
· Navigation: any function that determines and controls the navigational direction of a CST
vehicle.
· Monitoring: any function that monitors the state of CST systems for purposes of ensuring its
safety.
· Hazard Sensing: any function that senses hazards and/or displays information concerning the
protection of the CST system.
· Energy Control: any function that controls or regulates energy sources in the CST system.
· Fault Detection: any function that detects, prioritizes, or restores software faults with
corrective logic.
· Interrupt Processing: any function that provides interrupt priority schemes and routines to
enable or disable software-processing interrupts.
· Autonomous Control: any function that has autonomous control over safety-critical hardware.
· Safety Information Display: any function that generates and displays the status of safetycritical
hardware or software systems.
· Computation: any function that computes safety-critical data.
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
22
13.5.5 Software Safety Risk and Hazard Analysis
Risk Assessment
A key element in system safety program planning is the identification of the acceptable level of risk for
the system. The basis for this is the identification of hazards. Various methodologies used in the
identification of hazards are addressed in Sections 2.3 & 2.4 of draft AC 431.35-2. Once the hazards and
risks are identified, they need to be prioritized and categorize so that resources can be allocated to the
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册上(41)
