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

December 30, 2000
13 -
15
Figure 13-2: Interrelationship between Safety Critical Systems and Safety Critical Operations
Safety Critical Systems
• Design Standards for
systems
• Analysis, Tests,
Inspections
Safety Critical Operations
• Operations Standards for
Systems
• Analysis, Tests, Rehearsals,
Simulations, Controlled
Flight Tests
Vehicle Capabilities/Limitations Operational Capabilities/
Limitations
Public Risk
13.4.8 Determination of Risk to the Public
Expected casualty is used in the space transportation industry as a measure of risk to public safety.
Expected casualty is the expected average number of human casualties per mission. Human casualty is
defined as a fatality or serious injury. The application of the expected casualty analysis to determine
public risk is further defined in FAA Advisory Circular 431-02.
13.4.9 Determination of Need for Additional Risk Mitigation
The results of the expected casualty analysis may identify the need for additional risk mitigation measures
that need to be employed. These measures may include additional operational controls or may require the
redesign of certain safety critical systems. These additional risk mitigation measures would be evaluated
within the System Safety Process and the resultant risk to the public would be determined.
13.5 SOFTWARE SAFETY
13.5.1 Safety Critical Software
Safety-critical software plays an ever-increasing role in Commercial Space Transportation (CST)
computer systems. To preserve CST flight integrity, software-based hazards must be identified and
eliminated or reduced to acceptable levels of risk. Particular concern surrounds potential softwareinduced
accidents occurring during CST launch and reentry. Due to mission complexity, software failures
manifested at these critical times can cause serious accidents. Populated areas would suffer major harm if
defective software were to permit CST vehicles to violate their defined safety launch limits. Safetycritical
software, relative to CST launch vehicles, payloads and ground support equipment is inherently
defined as any software within a control system containing one or more hazardous or safety critical
functions. Safety critical functions are usually but not always associated with safety-critical systems.
Therefore, the following definition for safety –critical systems may also be applied to safety-critical
functions. A safety-critical system (or function) has been inherently defined as any system or subsystem
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
16
(or function) whose performance or reliability can affect (i.e. malfunction or failure will endanger) public
health, safety and safety of property.5
13.5.2 Systematic Software Safety Process
Introduction
The Systematic Software Safety Process (SSSP) encompasses the application of an organized periodic
review and assessment of safety-critical software and software associated with safety-critical system,
subsystems and functions. The Systematic Software Safety Process consist primarily of the following
elements:
·  Software safety planning
·  The software safety organization
·  A software safety team
·  Application of the software safety process during all life cycle phases
·  Identification and application of life cycle phase-independent software safety activities
·  Identification of special provisions
·  Software safety documentation
Software Safety Planning
Software system safety planning is deemed essential early in the software life cycle. Most importantly,
planning should impose provisions for accommodating safety well before each of the software design,
coding, testing, deployment and maintenance phases starts in the cycle. Moreover, these provisions are to
be planned carefully to impact minimally the software development process. The software system safety
plan should contain provisions assuring that:
·  Software safety organization is properly chartered and a safety team is commissioned in time.
·  Acceptable levels of software risk are defined consistently with risks defined for the entire
system.
·  Interfaces between software and the rest of the system’s functions are clearly delineated and
understood.
·  Software application concepts are examined to identify safety-critical software functions for
hazards.
·  Requirements and specifications are examined for safety hazards (e.g. identification of
hazardous commands, processing limits, sequence of events, timing constraints, failure
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊上(38)