n-version programming
TRANSCRIPT
Dependable Software System Course
Chapter 2 The Methodology of N-Version
ProgrammingBy: Shabnam shafie
Computer Engineering DepartmentGolestan University
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
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
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].
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
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)
Number Of Versions In NVP, deciding the number of versions required
to ensure acceptable levels of software reliability is an important design consideration.
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.
Version 2
Version 1
Version 3
Outputcomparator
N-versions
Agreedresult
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]
C-teammajor functions of the coordination team [1]:to prepare the final texts of the V-specs and of the test data setsto set up the implementation of the C&D protocolto acquaint all P-teams with the NVP processto distribute the V-specs, test and all other information needed by the P-teams to collect all P-team inquiries and evaluate them
Design paradigm For NVS
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]
Acceptancetest
Algorithm 2
Algorithm 1
Algorithm 3
Recoveryblocks
Test forsuccess
Retest
RetryRetest
Try algorithm1
Continue execution ifacceptance test succeedsSignal exception if allalgorithms fail
Acceptance testfails – re-try
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 voting. RB relies on acceptance test.
NVP & Recovery Block
NVP[1]
RB[1]
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
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
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 .