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

each phase of the program, permitting the best information available to direct the magnitude of the safety
program. The following steps applied to the risk methodology in Chapter 3 illustrate the technique used
for the program risk decision process.
·  Generate a CRA (and PHA if needed) in the IA phase. These analyses will provide the types
and risks of hazards. The development of an airframe and that of a ground communications
system could both produce a system that can lead to death, a Severity 1 or 2 hazard. A
development program that is far more complex and includes more Severity 1 or 2 hazards,
with a higher probability of occurrence than another, is clearly a high risk program, the other
a low risk one. The PHL includes information from sources such as safety, analytical, and
historical experience from similar systems and missions. The PHL process should be updated
and continued in the investment analysis phase.
·  Begin the Preliminary Hazard Analysis (PHA) as soon as possible. The PHA focuses on the
details of the system design. In addition to the historical experiences used for the PHL,
information about technologies, materials, and architectural features such as redundancy are
available as sources to the PHA. Systems using new and immature technologies or designs
are more risky than those that use proven technologies or modifications of existing designs.
·  Use a detailed hazard analysis to provide new and more precise information about safety risk
for the program production and deployment phases. This step will minimize the risk of
accidents during the test and evaluation process.
A major challenge that confronts government and industry organizations responsible for an SSP is the
selection of those tasks that can materially aid in attaining program safety requirements. Scheduling and
funding constraints mandate a cost-effective selection, one that is based on identified program needs. The
considerations presented herein are intended to provide guidance and rationale for this selection. They
are also intended to provoke questions and encourage problem solving by engineers, operations, and
support personnel.
After selection, the tasks must be identified and tailored to match the system and program specifications.
It is important to coordinate task requirements with other engineering support groups (e.g., reliability,
logistics) to eliminate duplication of tasks and to become aware of additional information of value to
system safety. The timing and depth required for each task, as well as action to be taken based on task
outcome, are program requirements. For these reasons, precise rules are not stated.
Some contractual activities provide cost savings, flexibility, and pre-award planning without affecting
compliance or control. These are:
·  Coordinate the delivery schedule of safety analysis deliverables with program milestones
such as a major design review rather than days after contract award. This prevents the need
for contractual changes to adjust for schedule changes. The deliverables should be provided
approximately 30 days prior to the milestones, thereby providing current information and the
ability of the reviewer to prepare for the design review. The deliverable can be established as
a major program milestone; however, this carries the risk of halting an entire program for a
single deliverable.
·  Consider requiring updates to the first deliverable rather than autonomous independent
deliverables at major milestones. For example, if the first system hazard analysis is
FAA System Safety Handbook, Chapter 5: Post-Investment Decision Safety Activities
December 30, 2000
5 - 28
scheduled for delivery at the Systems Design Review (SDR), the submittal required at the
Preliminary Design Review (PDR) might be limited to substitute and supplementary pages.
This requires planning such as configuration control requirements (e.g., page numbering and
dating schemes).
·  If major design decisions that significantly affect the cost of safety analyses are expected
during the contract, fix the size of the effort in a manner that maintains FAA control. An
example would be a flight control methodology decision such as would be applied to fly-bywire,
glass cockpit, or mechanical systems. The number of fault trees required in a safety
analysis depends on the system selected. A good contractual approach would be to fix the
number of fault trees to be provided during negotiations. The contract would reflect that both
the FAA and the contractor must agree on which fault trees are to be performed. Thus the
task can be tailored to the design well downstream from contract award without affecting
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊上(111)