N-version programming has been proposed as a method of incorporating fault tolerance into software. Multiple versions of a program (i.e. "N") are prepared and executed in parallel. Their outputs are collected and examined by a voter,and, if theyare not identical, it is assumed that the majority is correct. This method depends for its reliability improvement on the assumption that programs that have been developed independently will fail independently.Inthis paper an experiment is described in which the fundamental axiom is tested. Atotal of twenty sevenversions of a program were prepared independently from the same specification at twouniversities and then subjected to one million tests. The results of the tests revealed that the programs were individually extremely reliable but that the number of tests in which more than one program failed was substantially more than expected. The results of these tests are presented along with an analysis of some of the faults that were found in the programs. Background information on the programmers used is also summarized. The conclusion from this experiment is that N-version programming must be used with care and that analysis of its reliability must include the effect of dependent errors. Keywords and Phrases: Multi-version programming, N-version programming, software reliability,fault-tolerant software, design diversity. * This work was sponsored in part by NASA grant number NAG1-242 and in part by a MICROgrant cofunded by the state of California and Hughes Aircraft Company. 1.

After a system is deployed, fixes, enhancements, and modifications all occur that change the components that make up the system. Unfortunately, new versions of components can introduce new errors and break existing, depended-upon behavior. When this happens, the old component version could have provided the correct behavior, but it is no longer part of the system. We propose a framework for upgrading system components that, instead of removing the old version of the component, keeps multiple versions of a component running. Doing so allows behavior to be utilized from all versions, and maintains system integrity and correctness even in the presence of newly introduced errors. This framework ensures that the move towards dynamic, configurable software systems does not lessen, but rather provides capabilities to enhance, the reliability that software will achieve through the next century. 1 INTRODUCTION Users fear upgrades. This unfortunate but true statement reflects the current para...

Since its founding, NASA has been dedicated to the advancement of aeronautics and space science. The NASA Scientific and Technical Information (STI) Program Office plays a key part in helping NASA maintain this important role. The NASA STI Program Office is operated by Langley Research Center, the lead center for NASA's scientific and technical information. The NASA STI Program Office provides access to the NASA STI Database, the largest collection of aeronautical and space science STI in the world. The Program Office is also NASA's institutional mechanism for disseminating the results of its research and development activities. These results are published by NASA in the NASA STI Report Series, which includes the following report types: TECHNICAL PUBLICATION. Reports of completed research or a major significant phase of research that present the results of NASA programs and include extensive data or theoretical analysis. Includes compilations of significant scientific and technical data and information deemed to be of continuing reference value. NASA counterpart of peer-reviewed formal professional papers, but having less stringent limitations on manuscript length and extent of graphic presentations. TECHNICAL MEMORANDUM. Scientific and technical findings that are preliminary or of specialized interest, e.g., quick release reports, working papers, and bibliographies that contain minimal annotation. Does not contain extensive analysis.

In earlier studies of multiversion programming, both empirical and analytical, emphasis switched from notions of independence to one of minimization of coincident failure. We show that neither independence of failure, nor lack of coincident failure are the single important properties. Indeed, an N-version system may deliver an optimal performance (under some voting strategy) even when the incidence of coincident failure is arbitrarily high. The key notion that this study contributes is one of distinct different failure, and hence distinct-failure diversity. The important property is not whether versions fail on the same input so much as whether they fail in the same way. If the failures of an N-version system (on some input) are dispersed over a set of distinct alternative outcomes, then this (hitherto unacknowledged) aspect of diversity may be exploited to substantially enhance system reliability. We propose measures for the traditional coincident-failure diversity (CFD)...

N-version programming has long been mooted as a method of improving software reliability. Earlier studies, which generated apparently discouraging results, offered pessimistic prognostications for this general strategy. However, further study of the problem has both refined the evaluation procedure and revealed new opportunities for improvement. In particular, exploitation of methodological diversity has proved to be productive. In this paper, we continue such studies by introducing a methodological extreme, an inductive computing technology, neural computing, to extend an earlier study of Modula2 and Prolog versions of the Launch Interceptor problem. In addition, we examine several diversity measures which are presented as more reliable indicators of potential reliability enhancement than the earlier measures of independence of failure and, subsequently, of probability of two-version joint failure. We also examine several strategies for diversity exploitation in multiversio...

Abstract not found