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 .