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

not be available, shall be automated (i.e., not require ground personnel intervention to begin or complete).
The software shall notify ground personnel during or immediately after execution of an automated hazardous
or safing process.
Unused or undocumented codes shall be incapable of producing a critical or catastrophic hazard.
All safety critical elements (requirements, design elements, code modules, and interfaces) shall be identified
as "safety critical."
An application software set shall ensure proper configuration of inhibits, interlocks, and safing
logic, and exception limits at initialization.
Table J-1: Generic Software Safety Requirements listing
Coding Standards
Coding Standards, a class of generic software requirements, are, in practice, “safe” subsets of programming
languages. These are needed because most compilers can be unpredictable in how they work. For example,
dynamic memory allocation is predictable. In applications where some portions of memory are safety
critical, it is important to control which memory elements are assigned in a particular compilation process;
the defaults chosen by the compiler might be unsafe. Some attempts have been made at developing coding
safety standards (safe subsets).
Timing, Sizing and Throughput Considerations
System design should properly consider real-world parameters and constraints, including human operator and
control system response times, and flow these down to software. Adequate margins of capacity should be
provided for all these critical resources. This section provides guidance for developers in specifying
software requirements to meet the safety objectives. Subsequent analysis of software for Timing,
Throughput and Sizing considerations is discussed elsewhere in this appendix.
Time to Criticality: Safety critical systems sometimes have a characteristic “time to
criticality”, which is the time interval between a fault occurring and the system reaching an
unsafe state. This interval represents a time window in which automatic or manual recovery
and/or safing actions can be performed, either by software, hardware, or by a human
operator. The design of safing/recovery actions should fully consider the real-world
conditions and the corresponding time to criticality. Automatic safing can only be a valid
hazard control if there is ample margin between worst case (long) response time and worst
case (short) time to criticality.
Automatic safing is often required if the time to criticality is shorter than the realistic
human operator response time, or if there is no human in the loop. This can be performed by
either hardware or software or a combination depending on the best system design to achieve
safing.
Control system design can define timing requirements. Based on the established body of
classical and modern dynamic control theory, such as dynamic control system design, and
multivariable design in the s-domain (Laplace transforms) for analog continuous processes.
Systems engineers are responsible for overall control system design. Computerized control
systems use sampled data (versus continuous data). Sampled analog processes should make
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-10
use of Z-transforms to develop difference equations to implement the control laws. This
will also make most efficient use of real-time computing resources.
Sampling rates should be selected with consideration for noise levels and expected
variations of control system and physical parameters. For measuring signals that are not
critical, the sample rate should be at least twice the maximum expected signal frequency to
avoid aliasing. For critical signals, and parameters used for closed loop control, it is
generally accepted that the sampling rate must be much higher; at least a factor of ten above
the system characteristic frequency is customary.
Dynamic memory allocation: ensure adequate resources are available to accommodate
usage of dynamic memory allocation, without conflicts. Identify and protect critical
memory blocks. Poor memory management has been a leading factor in several critical
failures.
Memory Checking: Self-test of memory usage can be as part of BIT/self-test to give
advance warning of imminent saturation of memory.
Quantization: Digitized systems should select word-lengths long enough to reduce the
effects of quantization noise to ensure stability of the system. Selection of word-lengths and
floating-point coefficients should be appropriate with regard to the parameters being processed
in the context of the overall control system. Too short word-lengths can result in system
instability and misleading readouts. Too long word-lengths result in excessively complex
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊下(131)