the methodology of N-version programming a Fault tolerance technique

1. Dependable Software System Course
Chapter 2
The Methodology of N-Version
Programming
By: Shabnamshafie
ComputerEngineering Department
Golestan University

2. Outline
 Introduction
 What is NVP
 Design Diversity
 Number of Versions
 Output Comparison
 V-spec
 C-team
 Design paradigm For NVS
 Recovery Block
 NVP and Recovery Block
 Techniques Based on NVP
 Conclusion
 References

3. Introduction
 NVP ( N-Version Programming)
 The concept of N-version programming was first introduced
by Avizienis in 1977 [1]
 The same specification is implemented in a number of
different versions by different teams [1]
 All versions compute simultaneously and the majority output
is selected using a voting system [1]
 This is the most commonly used approach e.g. in Airbus
320.
Avizienis

4. What is NVP?
 With N-Version Programming, NVP, independent
development teams use the same specification to
generate multiple implementations.
 During development the design teams are kept separate
and do not share their designs nor do they discuss the
specification’s meaning with each other.
 The design teams should use different algorithms and
different programming languages to produce multiple
versions that contain different faults from the other
versions [1].

5. What is NVP?
 NVP can tolerate both hardware and software faults.
 Correlated faults are not tolerated by the NVP.
 There is some empirical evidence that teams commonly
misinterpret specifications in the same way and chose
the same algorithms in their systems.
Version 1
Version 2
Version 3
Voter OutputInput
Decider

6. Design Diversity
 NVP is based on the principle of design diversity, that is
coding a software module by different teams of
programmers, to have multiple versions [2]
 The diversity can also be introduced by employing
different algorithms for obtaining the same solution or by
choosing different programming languages [2]
Diversity in:
 Programming teams (personnel and structure)
 Software architecture
 Algorithms used
 Programming languages
 Verification tools and methods
 Data (input re-expression and output adjustment)

7. Number Of Versions
 In NVP, deciding the number of versions required to
ensure acceptable levels of software reliability is an
important design consideration.

8. Output comparison
 As in hardware systems, the output comparator is a
simple piece of software that uses a voting mechanism
to select the output.
 In real-time systems, there may be a requirement that
the results from the different versions are all produced
within a certain time frame.
Version2
Version1
Version3
Output
comparator
N-versions
Agreed
result

9. V-spec
 V-spec is the specification of the member versions
 It represents the starting point of the NVP process
 the V-spec needs to state the functional requirements
completely and unambiguously, while leaving the widest
possible choice of implementations [1]

10. C-team
major functions of the coordination team [1]:
to prepare the final texts of the V-specs and of the test data sets
to set up the implementation of the C&D protocol
to acquaint all P-teams with the NVP process
to distribute the V-specs, test and all other information needed by the
P-teams
 to collect all P-team inquiries and evaluate them

11. Design paradigm For NVS

12. Recovery Block
 Force a different algorithm to be used for each version so they
reduce the probability of common errors
 However, the design of the acceptance test is difficult as it must be
independent of the computation used
 There are problems with this approach for real-time systems
because of the sequential operation of the redundant versions [3]
Acceptance
test
Algorithm2
Algorithm1
Algorithm3
Recovery
blocks
Test for
success
Retest
Retry
Retest
Tryalgorithm
1
Continueexecutionif
acceptance testsucceeds
Signalexceptionif all
algorithms fail
Acceptancetest
fails –re-try

13. NVP & Recovery Block
 NVP is a forward recovery scheme - it masks faults.
 RB is a backward error recovery scheme.
 In NVP, multiple versions of the same task is executed
concurrently, whereas in RB scheme, the versions of a
task are executed serially[1].
 NVP relies on vo ting .
 RB relies on acce ptance te st.

14. NVP & Recovery Block
NVP[1]
RB[1]

15. Techniques Based on NVP
 N-Version Programming Tie Broker [4]
 N-Version Programming and Acceptance
Test[4]
 N-Version Programming-Tie Broker-
Acceptance Test[4]
 N-Self Checking Programming [5]
 Alternative one

16. Conclusion
 N-version programming and recovery blocks are two different
approaches to designing fault-tolerant software architectures
 In NVP, The same specification is implemented in a number of
different versions by different teams
 During development the design teams are kept separate and do not
share their designs nor do they discuss the specification’s meaning
with each other
 The major function of the coordination team is managing the P-
teams
 The purpose of the design paradigm is to integrate the unique
requirements of NVP with the conventional steps of software
development methodology
 NVP is based on Voter, but RB is based on Acceptance test

17. References
]1[Avizienis A.. "The Methodology Of N-Version Programming", Software Fault Tolerance, vol.3
pp.23-46, 1995.
]2[A. Avizienis and J. PJ Kelly. Fault tolerance by design diversity: Conceptsand experiments.
Computer, 17(8):67–80, 1984
]3[Pullum L. L., "Software fault tolerance techniques and implementation": Artech House Publishers,
2001
]4[Banki H., Babamir S., Farokh A., Morovati M., "Enhancing Efficiency of Software Fault Tolerance
Techniques Satellite Motion System", Journal of Information Systems and Telecommunication, Vol.
2, September 2014.
]5[Xie Z., Sun H., Saluja K., "A Survey of Software Fault Tolerance Techniques", University of
Wisconsin-Madison, 2007.