N-version programming explained

N-version programming (NVP), also known as multiversion programming or multiple-version dissimilar software, is a method or process in software engineering where multiple functionally equivalent programs are independently generated from the same initial specifications.^[1] The concept of N-version programming was introduced in 1977 by Liming Chen and Algirdas Avizienis with the central conjecture that the "independence of programming efforts will greatly reduce the probability of identical software faults occurring in two or more versions of the program". The aim of NVP is to improve the reliability of software operation by building in fault tolerance or redundancy.

NVP approach

The general steps of N-version programming are:

1. An initial specification of the intended functionality of the software is developed. The specification should unambiguously define: functions, data formats (which include comparison vectors, c-vectors, and comparison status indicators, cs-indicators), cross-check points (cc-points), comparison algorithm, and responses to the comparison algorithm.^[2]
2. From the specifications, two or more versions of the program are independently developed, each by a group that does not interact with the others. The implementations of these functionally equivalent programs use different algorithms and programming languages. At various points of the program, special mechanisms are built into the software which allow the program to be governed by the N-version execution environment (NVX). These special mechanisms include: comparison vectors (c-vectors, a data structure representing the program's state), comparison status indicators (cs-indicators), and synchronization mechanisms. The resulting programs are called N-version software (NVS).
3. Some N-version execution environment (NVX) is developed which runs the N-version software and makes final decisions of the N-version programs as a whole given the output of each individual N-version program. The implementation of the decision algorithms can vary ranging from simple as accepting the most frequently occurring output (for instance, if a majority of versions agree on some output, then it is likely to be correct) to some more complex algorithm.^[3]

Criticisms

• Researchers have argued that different programming teams can make similar mistakes.^[4] In 1986, Knight & Leveson conducted an experiment to evaluate the assumption of independence in NVP, they found that the assumption of independence of failures in N-version programs failed statistically.^{[5] [6]}
• The weakness of an NVP program lies in the decision algorithm. The question of correctness of an NVP program depends partially on the algorithm the NVX uses to determine what output is "correct" given the multitude of outputs by each individual N-version program. In theory, output from multiple independent versions is more likely to be correct than output from a single version. However, there is debate whether or not the improvements of N-version development is enough to warrant the time, additional requirements, and costs of using the NVP method. In particular, under certain models of reliability and design effort, it has been shown that improvements due to using NVP are less than if all of the effort was concentrated on improving the reliability of a single version.^[7]
• “There has been considerable debate as to realizing the full potential from n-version programming as it makes the assumption that the independence will lead to statistically independent mistakes. Evidence has shown that this premise may be faulty [12].” http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-01-26_COTS.pdf

Applications

N-version programming has been applied to software in switching trains, performing flight control computations on modern airliners, electronic voting (the SAVE System), and the detection of zero-day exploits, among other uses.

See also

• Redundancy (engineering)
• Triple modular redundancy
• Data redundancy
• Fault tolerant design
• Reliability engineering
• Safety engineering

External links

• N-version programming in the RKBExplorer

Notes and References

1. https://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=532621 N-Version Programming: A Fault-Tolerance Approach to Reliability of Software Operation
2. A.A. Avizienis, “The Methodology of N-version Programming”, Software Fault Tolerance, edited by M. Lyu, John Wiley & Sons, 1995.
3. Liburd, Soyini. An N-version electronic voting system (Thesis). Massachusetts Institute of Technology. Dept. of Electrical Engineering and Computer Science, 2004.
4. Lajos Nagy, Richard Ford, and William Allen. N-Version Programming for the Detection of Zero-day Exploits. The 2006 IEEE Topical Conference on Cybersecurity, Daytona Beach, Florida, April 2006.
5. Knight, J. C. and Leveson, N. G. 1986. An experimental evaluation of the assumption of independence in multiversion programming. IEEE Trans. Softw. Eng. 12, 1 (Jan. 1986), 96-109.
6. Knight, J. C. and Leveson, N. G. 1990. A reply to the criticisms of the Knight & Leveson experiment. SIGSOFT Softw. Eng. Notes 15, 1 (Jan. 1990), 24-35.
7. ((Sha, L.)) . IEEE Software . Using simplicity to control complexity . 18 . 4 . 20–28 . July 2001 . 1937-4194 . 10.1109/MS.2001.936213.