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

tolerance in software. The approach requires the separate, independent preparation of multiple (i.e. ‘‘N’’)
versions of a piece of software for some application. These versions are executed in parallel in the
application environment; each receives identical inputs and each produces its version of the required
outputs. The outputs are collected by a voter and, in principle, they should all be the same. In practice
there may be some disagreement. If this occurs, the results of the majority (assuming there is one) are
assumed to be the correct output, and this is the output used by the system.
Separate development can start at different points in the software development process. Since each
version of the software must provide the same functional capability, there must exist some common form of
system requirements document. Coordination must also exist if the versions are to provide data to the
voter, especially if intermediate data is compared as well as the final output data. Obviously, all design
specification must be redundant and independent for the versions to have any chance of avoiding common
design faults. An interesting approach to dual specification was used by Ramamoorthy et al. [2] where two
independent specifications were written in a formal specification language and then formal mathematical
techniques used to verify consistency between the specifications before the next step in development
proceeded. Thus they were able to detect specification faults by using redundancy and then repair them
before the separate software versions were produced. Kelly and Avizienis [3,4] also used separate
specifications for their N-version programming experiment, but the specifications were all written by the
same person so independence was syntactic only (three different specification languages were used).
N-version programming is faced with several practical difficulties in its implementation such as
isolation of the versions and design of voting algorithms. These difficulties have been summarized
comprehensively by Anderson and Lee [5] and will not be discussed here.
- 1 -
The great benefit that N-version programming is intended to provide is a substantial improvement in
reliability. It is assumed in the analysis of the technique that the N different versions will fail
independently; that is, faults in the different versions occur at random and are unrelated. Thus the
probability of two or more versions failing on the same input is very small. Under this assumption, the
probability of failure of an N-version system, to a first approximation, is proportional to the N’th power of
the probability of failure of the independent versions. If the assumption is true, system reliability could be
higher than the reliability of the individual components.
We are concerned that this assumption might be false. Our intuition indicates that when solving a
difficult intellectual problem (such as writing a computer program), people tend to make the same mistakes
(for example, incorrect treatment of boundary conditions) even when they are working independently.
Some parts of a problem may be inherently more difficult than others. In the experiment described in this
paper, the subjects were asked in a questionnaire to state the parts of the problem that caused them the most
difficulty. The responses were surprisingly similar.
It is interesting to note that, even in mechanical systems where redundancy is an important technique
for achieving fault tolerance, common design faults are a source of serious problems. An aircraft crashed
recently because of a common vibration mode that adversely affected all three parts of a triply redundant
system [6]. Common Failure Mode Analysis is used in critical hardware systems in an attempt to
determine and minimize common failure modes.
If the assumption of independence is not born out in practice for an N-version software system, it
would cause the analysis to overestimate the reliability. Recent work [7] has shown that even small
probabilities of coincident errors cause a substantial reduction in reliability. This could be an important
practical problem since N-version programming is being used in existing crucial systems and is planned for
others. For instance, dual programming has been used in the slat and flap control system of the Airbus
Industrie A310 aircraft [8]. The two programs are executed by different microprocessors operating
- 2 -
asynchronously. The outputs of the two microprocessors are compared continuously, and any difference
greater than a defined threshold causes the system to disconnect after a preset time delay. On the A310, it
is sufficient to know that there has been a failure as backup procedures allow the continued safe flight and
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料35(185)