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

specifications, emulators and Pseudo-Code Program Description Language products (PDL). Preliminary
code produced by code generators within case tools should be evaluated. Many techniques to be used on the
final code can be "dry run" on these design products. In fact, it is recommended that all analyses planned on
the final code should undergo their first iteration on the code-like products of the detailed design. This will
catch many errors before they reach the final code where they are more expensive to correct. The following
techniques can be used during this design phase. Description of each technique follows the list.
·  J.5.1 Design Logic Analysis
·  J.5.2 Design Data Analysis
·  J.5.3 Design Interface Analysis
·  J.5.4 Design Constraint Analysis
·  J.5.6 Software Fault Tree Analysis (SFTA)
·  J.5.7 Petri-Nets
·  J.5.8 Dynamic Flowgraph Analysis
·  J.5.9 Measurement of Complexity
·  J.5.10 Safe Subsets of Programming languages
·  J.5.11 Formal Methods and Safety-Critical Considerations
·  J.5.12 Requirements State Machines
J.5.1 Design Logic Analysis (DLA)
Design Logic Analysis (DLA) evaluates the equations, algorithms, and control logic of the software design.
Logic analysis examines the safety-critical areas of a software component. A technique for identifying
safety-critical areas is to examine each function performed by the software component. If it responds to, or
has the potential to violate one of the safety requirements, it should be considered critical and undergo logic
analysis. A technique for performing logic analysis is to analyze design descriptions and logic flows and
note discrepancies.
The ultimate, fully rigorous DLA uses the application of Formal Methods (FM). Where FM is
inappropriate, because of its high cost versus software of low cost or low criticality, simpler DLA can be
used. Less formal DLA involves a human inspector reviewing a relatively small quantity of critical software
artifacts (e.g. PDL, prototype code), and manually tracing the logic. Safety critical logic to be inspected can
include failure detection/diagnosis; redundancy management, variable alarm limits, and command inhibit
logical preconditions.
Commercial automatic software source analyzers can be used to augment this activity, but should not be
relied upon absolutely since they may suffer from deficiencies and errors, a common concern of COTS tools
and COTS in general.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-14
J.5.2 Design Data Analysis
Design data analysis evaluates the description and intended use of each data item in the software design.
Data analysis ensures that the structure and intended use of data will not violate a safety requirement. A
technique used in performing design data analysis is to compare description-to-use of each data item in the
design logic.
Interrupts and their effect on data must receive special attention in safety-critical areas. Analysis should
verify that interrupts and interrupt handling routines do not alter critical data items used by other routines.
The integrity of each data item should be evaluated with respect to its environment and host. Shared
memory, and dynamic memory allocation can affect data integrity. Data items should also be protected from
being overwritten by unauthorized applications. Considerations of EMI affecting memory should be
reviewed in conjunction with system safety.
J.5.3 Design Interface Analysis
Design interface analysis verifies the proper design of a software component's interfaces with other
components of the system. This analysis will verify that the software component's interfaces have been
properly designed. Design interface analysis verifies that control and data linkages between interfacing
components have been properly designed. Interface requirements specifications are the sources against which
the interfaces are evaluated.
Interface characteristics to be addressed should include data encoding, error checking and synchronization.
The analysis should consider the validity and effectiveness of checksums and CRCs. The sophistication of
error checking implemented should be appropriate for the predicted bit error rate of the interface. An overall
system error rate should be defined, and budgeted to each interface. Examples of interface problems:
·  Sender sends eight-bit word with bit 7 as parity, but recipient believes bit 0 is parity.
·  Sender transmits updates at 10 Hz, but receiver only updates at 1 Hz.
·  Sender encodes word with leading bit start, but receiver decodes with trailing bit start.
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊下(134)