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

can detect potential problems resulting in changes at the early stages of development
where such changes are relatively easy and less costly than at later stages.
·  They can be applied for the determination of worst case analysis and the potential
risks of timing failures.
·  A system approach is possible with Petri-nets since hardware, software and human
behavior can be modeled using the same language.
·  Petri-nets can be used at various levels of abstraction.
·  Petri-nets provide a modeling language which can be used for both formal analysis
and simulation.
Adding time and probabilities to each Petri-net allows incorporation of timing and
probabilistic information into the analysis. The model may be used to analyze the
system for other features besides safety.
Unfortunately, Petri-nets require a large amount of detailed analysis to build even relatively small systems,
thus making them very expensive. In order to reduce expenses, a few alternative Petri-net modeling
techniques have been proposed, each tailored to perform a specific type of safety analysis. For example,
time Petri-net (TPN), take account for time dependency factor of real-time systems; inverse Petri-net,
specifically needed to perform safety analysis, uses the previously discussed backward modeling approach to
avoid modeling all of the possible reachable status; and critical state inverse Petri-nets, which further refine
inverse Petri-net analysis by only modeling reachable states at predefined criticality levels.
Petri-net analysis can be performed at any phase of the software development cycle; though, it is highly
recommended for reasons of expense and complexity that the process be started at the beginning of the
development cycle and expanded for each of the succeeding phases. Petri-net, inverse Petri-net and critical
state Petri-nets are all relatively new technologies, are costly to implement, and absolutely require technical
expertise on the part of the analyst. Petri net analysis is a complex subject, and is treated in more detail in
Appendix C of this handbook.
J.5.8 Dynamic Flowgraph Analysis
Dynamic Flowgraph Analysis is a new technique, not yet widely used and still in the experimental phase of
evaluation. It does appear to offer some promise, and in many respects combines the benefits of
conventional J.5.6 Software Fault Tree Analysis (SFTA) and J.5.7 Petri-Nets .
The Dynamic Flowgraph Methodology (DFM) is an integrated, methodical approach to modeling and
analyzing the behavior of software-driven embedded systems for the purpose of dependability assessment
and verification. The methodology has two fundamental goals: 1) to identify how events can occur in a
system; and 2) identify an appropriate testing strategy based on an analysis of system functional behavior.
To achieve these goals, the methodology employs a modeling framework in which models expressing the
logic of the system being analyzed are developed in terms of contributing relationships between physical
variables and temporal characteristics of the execution of software modules.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-17
Models are analyzed to determine how a certain state (desirable or undesirable) can be reached. This is done
by developing timed fault trees which take the form of logical combinations of static trees relating the system
parameters at different points in time. The resulting information concerning the hardware and software states
that can lead to certain events of interest can then be used to increase confidence in the system, eliminate
unsafe execution paths, and identify testing criteria for safety critical software functions.
J.5.9 Measurement of Complexity
Software's complexity should be evaluated in order to determine if the level of complexity may contribute to
areas of concern for workability, understandability, reliability and maintainability. Highly complex data and
command structures are difficult, if not impossible, to test thoroughly and can lead to errors in logic either in
the initial build or in subsequent updates. Not all paths can usually be thought out or tested for and this
leaves the potential for the software to perform in an unexpected manner. Highly complex data and
command structures may be necessary, however, there usually are techniques for avoiding too high a level of
programming interweaving.
Linguistic, structural, and combined metrics exist for measuring the complexity of software and while
discussed below briefly.
Use complexity estimation techniques, such as McCabe or Halstead. If an automated tool is available, the
software design and/or code can be run through the tool. If there is no automated tool available, examine the
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊下(136)