Page 371 -

354 Chapter 13 Dependability engineering

same time. This requires the software to be written by different teams who should not
communicate during the development process, therefore reducing the chances of
common misunderstandings or misinterpretations of the specification.
The company that is procuring the system may include explicit diversity policies that
are intended to maximize the differences between the system versions. For example:

1. By including requirements that different design methods should be used. For
example, one team may be required to produce an object-oriented design and
another team may produce a function-oriented design.

2. By stipulating that the implementations are to be written in different program-
ming languages. For example, in a three-version system, Ada, C++, and Java
could be used to write the software versions.
3. By requiring the use of different tools and development environments for the system.
4. By explicitly requiring different algorithms to be used in some parts of the
implementation. However, this limits the freedom of the design team and may
be difficult to reconcile with system performance requirements.
Each development team should work with a detailed system specification (some-
times called the V-spec) that has been derived from the system requirements specifi-
cation (Avizienis, 1995). This should be sufficiently detailed to ensure that there are
no ambiguities in the specification. As well as specifying the functionality of the
system, the detailed specification should define where system outputs for compari-
son should be generated.
Ideally, the diverse versions of the system should have no dependencies and so
should fail in completely different ways. If this is the case, then the overall reliabil-
ity of a diverse system is obtained by multiplying the reliabilities of each channel.
So, if each channel has a probability of failure on demand of 0.001, then the overall
POFOD of a three-channel system (with all channels independent) is a million times
greater than the reliability of a single-channel system.
In practice, however, achieving complete channel independence is impossible. It
has been shown experimentally that independent design teams often make the same
mistakes or misunderstand the same parts of the specification (Brilliant, et., 1990;
Knight and Leveson, 1986; Leveson, 1995). There are several reasons for this:

1. Members of different teams are often from the same cultural background and may
have been educated using the same approach and textbooks. This means that they
may find the same things difficult to understand and have common difficulties in
communicating with domain experts. It is quite possible that they will, independ-
ently, make the same mistakes and design the same algorithms to solve a problem.
2. If the requirements are incorrect or they are based on misunderstandings about
the environment of the system, then these mistakes will be reflected in each
implementation of the system.

3. In a critical system, the V-spec is a detailed document based on the system’s
requirements, which provides full details to the teams on how the system should