曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
further analysis beyond the architectural design level. System risk assessment of hazards as described in the
NHB 1700 series of documents, consists of ranking risks by severity level versus probability of occurrence.
This high-severity/high probability risks are prioritized higher for analysis and corrective action than lowseverity/
low probability risks.
While Requirements Criticality and Update Criticality analysis simply assign a Yes or No to whether each
component is safety critical, the Risk Assessment process takes this further. Each SCCSCs is prioritized for
analysis and corrective action according to the five levels of Hazard Prioritization ranking given previously.
J.4.4 Analyze Architectural Design
The safety activity analyzes the Architectural Design of those SCCSCs identified in the preceding paragraphs
to ensure all safety requirements are specified correctly and completely in the Architectural Design. In
addition, the safety activity determines where in the Architectural Design, and under what conditions
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-12
unacceptable hazards occur. This is done by postulating credible faults/failures and evaluating their effects
on the system. Input/output timing, multiple event, out-of-sequence event, failure of event, wrong event,
inappropriate magnitude, incorrect polarity, adverse environment, deadlocking, and hardware failure
sensitivities are included in the analysis.
Methods used for FMEA (Failure Modes and Effects Analysis) can be used substituting software
components for hardware components in each case. A widely used FMEA procedure is MIL-STD-1629,
which is based on the following eight steps. Formal Inspections (described earlier), design reviews and
animation/simulation augment this process.
1. Define the system to be analyzed
2. Construct functional block diagrams
3. Identify all potential item and interface failure modes
4. Evaluate each failure mode in terms of the worst potential consequences
5. Identify failure detection methods and compensating provisions
6. Identify corrective design or other actions to eliminate / control failure
7. Identify impacts of the corrective change
8. Document the analysis and summarize the problems which could not be corrected
Design Reviews
Design data is reviewed to ensure it properly reflects applicable software safety requirements. Design
changes are generated where necessary. Applicability matrices, compliance matrices, and compliance
checklists can be used to assist in completing this task. Output products are engineering change requests,
hazard reports (to capture design decisions affecting hazard controls and verification) and action items.
Animation/Simulation
Simulators, prototypes (or other dynamic representations of the required functionality as specified by the
design), and test cases to exercise crucial functions can be developed. Run the tests and observe the system
response. Requirements can be modified as appropriate. Documented test results can confirm expected
behavior or reveal unexpected behavior. The status of critical verifications is captured by hazard reports.
J.4.5 Interface Analysis
Interdependence Analysis
Examine the software to determine the interdependence among CSCs, modules, tables, variables, etc.
Elements of software that directly or indirectly influences SCCSCs are also identified as SCCSCs, and as
such should be analyzed for their undesired effects. For example, shared memory blocks used by two or
more SCCSCs. The inputs and outputs of each SCCSC are inspected and traced to their origin and
destination.
Independence Analysis
The safety activity evaluates available design documentation to determine the independence/dependence and
interdependence of SCCSCs to both safety-critical and non-safety-critical CSCs. Those CSCs that are found
to affect the output SCCSCs are designated as SCCSCs. Areas where FCR (Fault Containment Region)
integrity is compromised are identified. The methodology is to map the safety critical functions to the
software modules and map the software modules to the hardware hosts and FCRs. Each input and output of
each SCCSC should be inspected. Resources are definition of safety critical functions needing to independent
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-13
design descriptions, and data diagrams. Design changes to achieve valid FCRs and corrections to SCCSC
designations may be necessary
J.5 Detailed Design Analysis
During the Detailed Design phase, more detailed software artifacts are available, permitting rigorous
analyses to be performed. Detailed Design Analyses can make use of artifacts such as detailed design
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册下(133)
