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

Output products are the following:
·  Updated Safety Requirements Checklist
·  Definition of Safety Critical Requirements.
The results and findings of the Criticality Analyses should be fed to the System Requirements and System
Safety Analyses. For all discrepancies identified, either the requirements should be changed because they are
incomplete or incorrect, or else the design must be changed to meet the requirements. The analysis identifies
additional hazards that the system analysis did not include, and identifies areas where system or interface
requirements were not correctly assigned to the software.
The results of the criticality analysis may be used to develop Formal Inspection checklists for performing the
formal inspection process described later in INSERT REFERENCE.
Critical Software Characteristics
Many characteristics are governed by requirements, but some may not be.
All characteristics of safety critical software must be evaluated to determine if they are safety critical. Safety
critical characteristics should be controlled by requirements that receive rigorous quality control in
conjunction with rigorous analysis and test. Often all characteristics of safety critical software are
themselves safety critical.
Characteristics to be considered include at a minimum:
·  Specific limit ranges
·  Out of sequence event protection requirements (e.g., if-then statements)
·  Timing
·  Relationship logic for limits. Allowable limits for parameters might vary depending on
operational mode or mission phase. Expected pressure in a tank varies with
temperature, for example.
·  Voting logic
·  Hazardous command processing requirements (fault response
·  Fault detection, isolation, and recovery
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-7
·  Redundancy management/switchover logic; what to switch and under what
circumstances, should be defined as methods to control hazard causes identified in the
hazards analyses. For example, equipment that has lost control of a safety critical
function should be switched to a good spare before the time to criticality has expired.
Hot standby units (as opposed to cold standby) should be provided where a cold start
time would exceed time to criticality.
This list is not exhaustive and often varies depending on the system architecture and environment.
J.3.3 Generic Software Safety Requirements
The generic category of software safety requirements are derived from sets of requirements and best
practices used in different programs and environments to solve common software safety problems. Similar
processors/platforms and/or software can suffer from similar or identical design problems. Generic software
safety requirements capture these lessons learned and provide a valuable resource for developers.
Generic requirements prevent costly duplication of effort by taking advantage of existing proven techniques
and lessons learned rather than reinventing techniques or repeating mistakes. Most development programs
should be able to make use of some generic requirement; however, they should be used with care.
As technology evolves, or as new applications are implemented, new "generic" requirements will likely arise,
and other sources of generic requirements might become available. A partial listing of generic requirement
sources is shown below:
·  EWRR (Eastern and Western Range Regulation) 127-1, Section 3.16.4 Safety Critical
Computing System Software Design Requirements.
·  AFISC SSH 1-1 System Safety Handbook - Software System Safety, Headquarters Air
Force Inspection and Safety Center.
·  EIA Bulletin SEB6-A System Safety Engineering in Software Development (Electrical
Industries Association)
·  Underwriters Laboratory - UL 1998 Standard for Safety - Safety-Related Software,
January 4th, 1994
A listing of many of the generic software safety requirements is presented in the table below.
The failure of safety critical software functions shall be detected, isolated, and recovered from such that
catastrophic and critical hazardous events are prevented from occurring.
Software shall perform automatic Failure Detection, Isolation, and Recovery (FDIR) for identified safety
critical functions with a time to criticality under 24 hours
Automatic recovery actions taken shall be reported. There shall be no necessary response from ground
operators to proceed with the recovery action.
The FDIR switchover software shall be resident on an available, non-failed control platform which is
　
中國航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊下(129)