曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
Input/Output Variables
All information from the sensors should be used somewhere in the RSM. If not, either an input from a
sensor is not required or, more importantly, an omission has been made from the software requirements
specification. For outputs it can be stated that, if there is a legal value for an output that is never produced,
then a requirement for software behavior has been omitted.
State Attributes
The state attributes of the RSM are to be labeled according to the scheme in Chapter 10.
J.6 Code Analysis
Code analysis verifies that the coded program correctly implements the verified design and does not violate
safety requirements. In addition, at this phase of the development effort, many unknown questions can be
answered for the first time. For example, the number of lines of code, memory resources and CPU loads can
be seen and measured, where previously they were only predicted, often with a low confidence level.
Sometimes significant redesign is required based on the parameters of the actual code. Code permits real
measurements of size, complexity and resource usage. Code Analyses include:
· Code Logic Analysis
· Software Fault Tree Analysis (SFTA)
· Petri-Nets
· Code Data Analysis
· Code Interface Analysis
· Measurement of Complexity
· Code Constraint Analysis
· Safe Subsets of Programming languages
· Formal Methods and Safety-Critical Considerations
· Requirements State Machines
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-22
Some of these code analysis techniques mirror those used in detailed design analysis. However, the results
of the analysis techniques might be significantly different than during earlier development phases, because
the final code may differ substantially from what was expected or predicted.
Each of these analyses, contained in this section, should be undergoing their second iteration, since they
should have all been applied previously to the code-like products (PDL) of the detailed design.
There are some commercial tools available which perform one or more of these analyses in a single package.
These tools can be evaluated for their validity in performing these tasks, such as logic analyzers, and path
analyzers. However, unvalidated COTS tools, in themselves, cannot generally be considered valid methods
for formal safety analysis. COTS tools are often useful to reveal previously unknown defects.
Note that the definitive formal code analysis is that performed on the final version of the code. A great deal
of the code analysis is done on earlier versions of code, but a final check on the final version is essential.
For safety purposes it is desirable that the final version have no “instrumentation” (i.e., extra code added), in
order to see where erroneous jumps go. One may need to run the code on an instruction set emulator that
can monitor the code from the outside, without adding the instrumentation.
J.6.1 Code Logic Analysis
Code logic analysis evaluates the sequence of operations represented by the coded program. Code logic
analysis will detect logic errors in the coded software. Performing logic reconstruction, equation
reconstruction and memory decoding conduct this analysis.
Logic reconstruction entails the preparation of flow charts from the code and comparing them to the design
material descriptions and flow charts.
Equation reconstruction is accomplished by comparing the equations in the code to the ones provided with
the design materials.
Memory decoding identifies critical instruction sequences even when they may be disguised as data. The
analyst should determine whether each instruction is valid and if the conditions under which it can be
executed are valid. Memory decoding should be done on the final un-instrumented code. Employment of
Fault Trees and Petri Nets has been discussed in the previous section of this appendix.
J.6.2 Code Data Analysis
Code data analysis concentrates on data structure and usage in the coded software. Data analysis focuses on
how data items are defined and organized. Ensuring that these data items are defined and used properly is
the objective of code data analysis. This is accomplished by comparing the usage and value of all data items
in the code with the descriptions provided in the design materials.
Of particular concern to safety is ensuring the integrity of safety critical data against being inadvertently
altered or overwritten. For example, check to see if interrupt processing is interfering with safety critical
data. Also, check the “typing” of safety critical declared variables.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册下(140)
