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

landing of the aircraft. Dual programming has also been applied to point switching, signal control, and
traffic control in the Gothenburg area by Swedish State Railways [9]. In the latter system, if the two
programs show different results, signal lights are switched to red. Dual programming has further been
proposed for safety systems in nuclear reactors. Voges, Fetsch, and Gmeiner [10] have proposed its use in
the design of a reactor shutdown system which serves the purpose of detecting cooling disturbances in a
fast breeder reactor and initializing automatic shutdown of the reactor in case of possible emergency. Also,
both Ramamoorthy et al. [2] and Dahll and Lahti[11] have proposed elaborate dual development
methodologies for the design of nuclear reactor safety systems.
A common argument [2,10,12] in favor of dual programming is that testing of safety-critical realtime
software can be simplified by producing two versions of the software and executing them on large
numbers of test cases without manual or independent verification of the correct output. The output is
assumed correct as long as both versions of the programs agree. The argument is made that preparing test
data and determining correct output is difficult and expensive for much real-time software. Since it is
assumed ‘‘unlikely’’ that two programs will contain identical faults, a large number of test cases can be run
in a relatively short time and with a large reduction in effort required for validation of test results.
In addition, it has been argued that each individual version of the software can have lower reliability
than would be necessary if only one version were produced. The higher required software reliability is
assumed to be obtained through the voting process*. The additional cost incurred in the development of
multiple software versions would be offset by a reduction in the cost of the validation process. It has even
been suggested [13] that elaborate software development environments and procedures will be unnecessary
- 3 -
and that mail-order software could be obtained from hobbyist programmers.
The important point to note is that all of the above arguments in favor of using redundant
programming hinge on the basic assumption that the probability of common mode failures (identical
incorrect output given the same input) is very low for independently developed software. Therefore, it is
important to know whether this assumption is correct.
Several previous experiments have involved N-version programming, but none have focused on the
issue of independence. In two [2,11] independence was assumed and therefore not tested. In each of these,
the two versions developed were assumed to be correct if the two outputs from the test cases agreed and no
attempt was made to verify independently the correctness of the output. Thus common errors would not
necessarily have been detected. In other experiments, common errors were observed but since
independence was not the hypothesis being tested, the design of the experiments make it impossible to draw
any statistically valid conclusions. Kelly and Avizienis [3,4] report finding 21 related faults, one common
fault was found in practical tests of the Halden nuclear reactor project [9], and Taylor [9] reports that
common faults have been found in about half of the practical redundant European software systems.
In summary, although there is some negative evidence which raises doubts about the independence
assumption, there has been no experiment which attempted to study this assumption in a manner in which
clear evidence for or against can be drawn. Because the independence assumption is widely accepted and
because of the potential importance of the issue in terms of safety, we have carried out a large scale
experiment in N-version programming to study this assumption. A statistically rigorous test of
independence was the major goal of the experiment and all of the design decisions that were taken were
dominated by this goal.
*One might note that even in the hardware Triple Modular Redundancy (TMR) systems, from which the idea of N-version programming
arises, overall system reliability is not improved if the individual components are not themselves sufficiently reliable [5]. In
fact, incorporating redundancy into a system can actually reduce overall system reliability due to the increased number of components
[14].
- 4 -
The experiment and its results are presented in the remainder of this paper. In section two we
describe the experiment itself, and we review the backgrounds of the programmers and their activities
during the experiment in section three. The results of the tests performed on the various versions are
presented in section four. Section five contains a model of independence and a statistical test of the
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料35(186)