7
RELIABILITY OPTIMIZATION
Reliability of Computer Systems and Networks: Fault Tolerance, Analysis, and Design
Martin L. Shooman
Copyright 
2002
John Wiley & Sons, Inc.
ISBNs:
0
-
471
-
29342
-
3
(Hardback);
0
-
471
-
22460
-X (Electronic)
331
7
.
1
INTRODUCTION
The preceding chapters of this book discussed a wide range of different tech-
niques for enhancing system or device fault tolerance. In some applications,
only one of these techniques is practical, and there is little choice among the
methods. However, in a fair number of applications, two or more techniques

tributed over the entire system in such a way that it optimizes reliability. The
optimization approach has been studied in the past, but is infrequently used in
practice for many reasons, such as (a) the system designer does not understand
the older techniques and the resulting mathematical formulation; (b) the solu-
tion takes too long; (c) the parameters are not well known; and (d) constraints
change rapidly and invalidate the previous solution. We propose a technique
that is clear, simple to explain, and results in the rapid calculation of a family
of good suboptimal solutions along with the optimal solution. The designer is
then free to choose among this family of solutions, and if the design features
or parameters change, the calculations can be repeated with modest effort.
We now postulate that the design of fault-tolerant systems can be divided
into three classes. In the first class, only one design approach (e.g., parallel,
standby, voting) is possible, or intuition and experience points only to a sin-
gle approach. Thus it is simple to decide on the level of redundancy required
to meet the design goal or the level allowed by the constraint. To simplify
our discussion, we will refer to cost, but we must keep in mind that all the
techniques to be discussed can be adapted to any other single constraint or,
in many cases, multiple constraints. Typical multiple constraints are cost, reli-
ability, volume, and weight. Sometimes, the optimum solution will not satisfy
the reliability goal; then, either the cost constraint must be increased or the
reliability goal must be lowered. In the second class, if there are two or three
alternative designs, we would merely repeat the optimization for each class
as discussed previously and choose the best result. The second class is one
in which there are many alternatives within the design approach because we
can apply redundancy at the subsystem level to many subsystems. The third
class, where a mixed strategy is being considered, also has many combinations.
To deal with the complexity of the third-class designs, we will use computer
computations and an optimization approach to guide us in choosing the best
alternative or set of alternatives.
7

occurs at xs, ys, and the other where the surface is a broad one and where the
reliability reaches zb

0
.
96
at a small peak located at xb, yb in the center of
a broad plateau having a height of
0
.
94
. Clearly, if we choose the spire as our
design and if parameters x or y are a little different than xs, ys, the reliability
may be much lower—below
0
.
96
and even below
0
.
94
—because of the steep
slopes on the flanks of the spire. Thus the maximum of
0
.
96
is probably a better
design and has less risk, since even if the parameters differ somewhat from xb,
yb, we still have the broad plateau where the reliability is
0

first step of the procedure. This process should reduce a large problem into a
number of smaller subproblems, the optimization of which we can approach by
using a bounded enumeration procedure. One can greatly reduce the size of the
solution space by establishing a sequence of bounds; the resulting subsystem
optimization is well within the power of a modern PC, and solution times are
reasonable. Of course, the first step in the process—that of apportionment—is
generally a good one, but it is not necessarily an optimum one. It does, how-
ever, fit in well with the philosophy alluded to in the previous section that a
broad, easy-to-achieve, easy-to-understand suboptimum is preferred in a prac-
tical case. As described later in this chapter, allocation tends to divert more
resources to the “weakest link in the chain.”
There are other important practical arguments for simplified semioptimum
334
RELIABILITY OPTIMIZATION
techniques instead of exact mathematical optimization. In practice, optimiz-
ing a design is a difficult problem for many reasons. Designers, often harried
by schedule and costs, look for a feasible solution to meet the performance
parameters; thus reliability may be treated as an afterthought. This approach
seldom leads to a design with optimum reliability—much less a good sub-
optimal design. The opposite extreme is the classic optimization approach, in
which a mathematical model of the system is formulated along with constraints
on cost, volume, weight, and so forth, where all the allowable combinations
of redundant parallel and standby components are permitted and where the
underlying integer programming problem is solved. The latter approach is sel-
dom taken for the previously stated reasons: (a) the system designer does not
understand the mathematical formulation or the solution process; (b) the solu-
tion takes too long; (c) the parameters are not well known; and (d) the con-
straints rapidly change and invalidate the previous solution. Therefore, clear,
simple, and rapid calculation of a family of good suboptimal solutions is a
sensible approach. The study of this family should reveal which solutions, if

1
(see Fig.
7
.
1
). Clearly, the components in the foregoing
mathematical model can be subsystems if we wish.
The system reliability is given by the probability of the event in which all
the components succeed (the intersection of their successes):
R
s

P(x
1
U
x
2
U
· · ·
U
x
k
)(
7
.
1
a)
If we assume that all the elements are independent, Eq. (
7
.

i
(
7
.
1
b)
We will let the single constraint on our design be the cost for illustrative
purposes, and the total cost, c, is given by the sum of the individual component
costs, c
i
:
c

k
Α
Α
Α
i

1
c
i
(
7
.
2
)
We assume that the system reliability given by Eq. (
7
.

all of the cost budget, c
0
, to fund redesign for higher reliability.
2
. Place components in parallel with the subsystems that operate contin-
336
RELIABILITY OPTIMIZATION
R,
11
n
R,
22
nR,
kk
n
.
.
.
.
.
.
.
.
.
Figure
7
.
2
The choice of redundant components to optimize the reliability of the
series system of Fig.

, we employ n
k
elements in
parallel to raise the reliability of each subsystem that we denote by R
k
(see
Fig.
7
.
2
).
The reliability of a parallel system of n
k
independent components is most
easily formulated in terms of the probability of failure (
1
− r
i
)
n
i
. For the struc-
ture of Fig.
7
.
2
where all failures are independent, Eq. (
7
.
1

k
Α
Α
Α
i

1
n
i
c
i
(
7
.
4
)
We can develop a similar formulation for standby redundancy.
7
.
4
.
2
Standby Redundancy
In the case of standby systems, it is well known that the probability of failure
is governed by the Poisson distribution (see Section A
5
.
4
).
HIERARCHICAL DECOMPOSITION

) and (
7
.
4
) becomes
R
s

k
∏
i

1
x
k

n
k
−
1
Α
Α
Α
x
k

0
P(x
k
; m

when the complexity of the resulting components is reduced to a level that puts
it within the “intellectual span of control” of one manager or senior designer.
This approach is generally called divide and conquer and is presented for use
on complex problems in books on algorithms [Aho,
1974
, p.
60
; Cormen,
1992
,
p.
12
]. The term probably comes from the ancient political maxim divide et
impera (“divide and rule”) cited by Machiavelli [Bartlett,
1968
, p.
150
b], or
possibly early principles of military strategy.
7
.
5
.
2
Graph Model
Although the decomposition of a large system is generally guided by expe-
rience and intuition, there are some guidelines that can be used to guide the
process. We begin by examining the structure of the decomposition. One can
338
RELIABILITY OPTIMIZATION

as the start vertex, then this (closed) path is called a cycle (loop). A graph
without cycles where all the nodes are connected is called a tree (the graph
corresponding to a hierarchical block diagram is a tree). The top vertex of a
tree is called the root (root node). In general, a node in the tree that corresponds
to a component with subcomponents is called a parent of the subcomponents,
which are called children. The root node is considered to be at depth
0
(level
0
); its children are at depth
1
(level
1
). In general, if a parent node is at level n,
then its children are at level n +
1
. The largest depth of any vertex is called the
depth of the tree. The number of children that a parent has is the out-degree,
and the number of parents connected to a child is the in-degree. A node that
has no children is the end node (terminal node) of a path from the root node
and is called a leaf node (external node). Nonleaf nodes are called internal
nodes. An example illustrating some of this nomenclature is given in Fig.
7
.
3
.
7
.
5
.

,
195
].) If we specify the out-degree
to be seven for each node and all the leaves (terminal nodes) to be at level
(depth) h, then the number of leaves at level h (NL
h
) is given by
NL
h

7
h
(
7
.
7
)
In practice, each leaf is the lowest level of replaceable unit, which is gen-
erally called a line replaceable unit (LRU). In the case of software, we would
probably call the analog of an LRU a module or an object. The total number
of nodes, N, in the graph can be computed if we assume that all the leaves
appear at level h.
N

NL
0
+ NL
1
+ NL
2


a(r
n
−
1
)
/
(r −
1
)(
7
.
9
a)
where
r

n

a

the common ratio (in our case,
7
)
the number of terms (in our case, h +
1
)
the first term (in our case,
1
)

1
)
/
6

57
. We can check this by substitution in
Eq. (
7
.
8
b), yielding
1
+
7
+
49

57
.
340
RELIABILITY OPTIMIZATION
7
.
5
.
4
Interface and Computation Structures
Another way of viewing a decomposition structure is to think in terms of two
classes of structures, interfaces, and computational elements—a breakdown

0
; however, let us consider the system specifi-
cations as a single interface at level
0
. Thus, we can use Eqs. (
7
.
8
) and (
7
.
9
) to
count the number of interfaces, which is equivalent to the number of elements.
Continuing the foregoing example where h

2
, we have
7
2

49
computational
elements and (
7
3
−
1
)
/

39
, Fig.
61
]. Level
0
in
our decomposition is the “air traffic control system.” At level
1
, we have the
major subsystems that are given in Table
7
.
1
.
An expert designer of a new ATC system might view things a little dif-
ferently (in fact, two expert designers working for different companies might
HIERARCHICAL DECOMPOSITION
341
TABLE
7
.
1
A Typical Air Traffic Control System at Level
1
•
Tracking radar and associated computer.
•
Air traffic control (ATC) displays and display computers.
•
Voice communications with pilot.

a level, the system will only succeed if all the subsystems succeed; thus the
system reliability, R
s
, can be expressed as
R
s

P(X
1
U
X
2
U
· · ·
U
X
7
)(
7
.
10
)
If the seven aforementioned subsystems are statistically independent, then
Eq. (
7
.
10
) becomes
R
s

7
.
10
).
Because of the nature of the probabilities, that is, they are bounded by
0
and
1
, and also because of the product nature of Eq. (
7
.
11
), we can bound each
of the terms. There is an infinite number of values of P(X
1
), P(X
2
), . . . , P(X
7
)
that satisfies Eq. (
7
.
11
); however, the smallest value of P(X
1
) occurs when
342
RELIABILITY OPTIMIZATION
P(X

.
12
c)
These minimum bounds are true in general for any subsystem if the system
structure is series; thus we can write
P(X
i
) ≥ R
s
(
7
.
13
)
The equality only holds in Eqs. (
7
.
12
) and (
7
.
13
) if all the other subsystems
have a reliability equal to unity (i.e., they never fail); thus, in the real world, the
equality conditions can be deleted. These minimum bounds will play a large
role in the optimization technique developed later in this chapter.
7
.
6
APPORTIONMENT

Alven,
1964
, Chapter
6
]; many of the methods discussed in this section are
an outgrowth of this early work. We continue to assume that there are about
7
subsystems at depth
1
. Our problem is how to allocate the reliability goal
among the subsystems, for which several procedures exist on which to base
such an allocation early in the design process; these are listed in Table
7
.
2
.
APPORTIONMENT
343
TABLE
7
.
2
Approaches to Apportionment
Approach Basis
Comments
Equal weighting All subsystems should have Easy first attempt.
the same reliability.
Relative difficulty Some knowledge of relative Heuristic method requiring
cost or difficulty to only approximate
improve subsystem ordering of cost

R
s

P(X
1
)P(X
2
) · · · P(X
7
)

r
7
(
7
.
14
a)
For the general case of n independent subsystems in series,
R
s

r
n
(
7
.
14
b)
Solving Eq. (

This equal weighting apportionment is so simple that it is probably one of the
first computations made in a project. System engineers typically “whip out”
their calculators and record such a calculation on the back of an envelope or
a piece of scrap paper during early discussions of system design.
As an example, suppose that we have a system reliability goal of
0
.
95
, in
which case Eq. (
7
.
15
a) would yield an apportioned goal of r

0
.
9927
. Of
course, it is unlikely that it would be equally easy or costly to achieve the
apportioned goal of
0
.
9927
for each of the subsystems. Thus this method gives
a ballpark estimate, but not a lot of time should be spent using it in the design
before a better method replaces it.
344
RELIABILITY OPTIMIZATION
7

2
r − r
2
)
3
(
7
.
16
)
Solving Eq. (
7
.
16
) numerically for a system goal of
0
.
95
yields r

0
.
9874
.
Thus the four “easier” subsystems would have a single system with a reliabil-
ity of
0
.
9874
, and the three harder systems would have two parallel systems

, or r

0
.
953
. Other similar solutions can easily be obtained.
The previous paragraph dealt with unequal apportionments by considering
a parallel system for the three harder systems. If we assume that parallel sys-
tems are not possible at this level, we must choose a solution where the easier
systems exceed a reliability of
0
.
9927
so that the harder systems can have a
smaller reliability. For convenience, we could rewrite Eq. (
7
.
11
) in terms of
unreliabilities, r
i

1
− u
i
, obtaining
R
s

(

bility u
5

u
6

2
u, and Eq. (
7
.
17
a) becomes
R
s

(
1
− u)
4
(
1
−
2
u)
3
that yields a
7
th-order polynomial.
The easiest way to solve the polynomial is through trial and error with a
calculator or by writing a simple program loop to calculate a range of values.

1
−
0
.
01
, and substitute in Eq. (
7
.
17
a), the
result is
0
.
951038

(
0
.
995
)
4
(
0
.
99
)
3
(
7
.

.
6
.
3
Relative Failure Rates
It is simpler to use knowledge about easier and harder systems during appor-
tionment if we work with failure rates. We assume that each subsystem has a
constant-failure rate l
i
and that the reliability for each subsystem is given by
r
i

e
−l
i
(
7
.
18
a)
and substitution of Eq. (
7
.
18
a) into Eq. (
7
.
11
) yields

R
s

e
−l
s
(
7
.
19
)
where
l
s

l
1
+ l
2
+ · · · + l
7
Continuing with our example of the previous section, in which the goal is
0
.
95
, the four “easier” systems have a failure rate of l, and the three harder
ones have a failure rate of
5
l, Eq. (
7

0
.
9973
, and e
−
5
×
0
.
0026996

0
.
9865
. Thus our apportioned goals for the four
easier systems are
0
.
9973
; for the three harder systems,
0
.
9865
. As a check,
we see that
0
.
9973
4
×

]. The procedure assumes that
initially there are some estimates of what reliabilities can be achieved for the
subsystems to be apportioned. In terms of our notation, we will say that P(X
1
),
P(X
2
), . . . , P(X
7
) are given by some nominal values: R
1
, R
2
, . . . , R
7
. Note that
we continue to speak of seven subsystems at level
1
; however, this clearly can
be applied to any number of subsystems. The fact that we assume nominal
values for the R
i
implies that we have a preliminary design. However, in any
large system there are many iterations in system design, and this method is
quite useful even if it is not the first one attempted. Adopting the terminology
of government contracting (which generally has parallels in the commercial
world), we might say that the methods of Sections
7
.
6

21
)
If the design team is lucky, R
s
> R
g
, and the first concerns about reliability
are thus satisfied. In fact, one might even think about trading off some reli-
ability for reduced cost. An experienced designer would tell us that this almost
never happens and that we are dealing with the situation where R
s
< R
g
. This
means that one or more of the R
i
values must be increased. Albert’s method
deals with finding which of the subsystem reliability goals must be increased
and by how much so that R
s
is increased to the point where R
s

R
g
.
Based on the bounds developed in Eq. (
7
.
13

increased. Albert’s method requires that all the j subsystems have their reli-
ability increased to the same value, r, and that the reliabilities of the (i − j )
subsystems remain unchanged. Thus, Eq. (
7
.
21
) becomes
R
g

R
1
R
2
·· ·R
j
R
j +
1
· · · R
7
(
7
.
22
)
where
R
1


j +
1
· · · R
7
)(
7
.
24
)
We solve Eq. (
7
.
24
) for the value of r (or, more generally, r
i
):
r
j

R
g
/
(R
j +
1
· · · R
7
)(
7
.

must still be discussed: how to determine the value of j. Again, we turn to
Eq. (
7
.
13
) to shed some light on this question. We can place a lower bound
on j and say that all the subsystems having reliabilities smaller than or equal
to the goal, R
i
< R
g
, must be increased. It is possible that if we choose j equal
to this lower bound and substitute into Eq. (
7
.
25
b), the computed value of
r will be >
1
, which is clearly impossible; thus we must increase j by
1
and
try again. This process is repeated until the values of r obtained are <
1
. We
now have a feasible value for j, but we may be requiring too much “effort” to
raise all the
1
through j subsystems to the resulting high value of r. It may be
better to increment j by

0
.
7
, R
2

0
.
8
, R
3

0
.
9
, and R
4

0
.
95
,
and the system reliability goal is R
g

0
.
8
. The existing estimates predict a
system reliability of R

2
, so we begin
348
RELIABILITY OPTIMIZATION
our calculations at this point. The system reliability goal, R
g

0
.
8
, and Eq.
(
7
.
25
b) yields
r

(R
g
/
[R
j +
1
· · · R
7
])
1
/
j

(
7
.
26
)
Since
0
.
96730
>
0
.
9
, we continue our calculation. We now recompute for
subsystems
1
,
2
, and
3
, and Eq. (
7
.
25
b) yields
r

(
0
.

As a check, we now compute the system reliability.
0
.
96730
×
0
.
96730
×
0
.
9
×
0
.
95

0
.
7999972

R
g
which equals our goal of
0
.
8
when rounded to one place. Thus, the conclusion
from the use of Albert’s method is that the apportionment goals for the four
systems are R

271
]:
1
. Each subsystem has the same effort function that governs the amount of
effort required to raise the reliability of the ith subsystem from R
i
to r
i
.
This effort function is denoted by G(R
i
, r
i
), and increased effort always
increases the reliability: G(R
i
, r
i
) ≥
0
.
2
. The effort function G(x, y) is nondecreasing in y for fixed x, that is, given
an initial value of R
i
, it will always require more effort to increase r
i
to
a higher value. For example,
G(

65
) ≥ G(
0
.
35
,
0
.
65
)
3
. If x ≤ y ≤ z, then G(x, y) + G( y, z)

G(x, z). This is a superposition
(linearity) assumption that states that if we increase the reliability in two
steps, the sum of the efforts for each step is the same as if we did the
increase in a single step.
4
. G(
0
, x) has a derivative h(x) such that xh(x) is strictly increasing in (
0
<
x <
1
).
APPORTIONMENT
349
The proof of the algorithm is given in Albert [
1958

7
.
6
) (or else improve the LRU reliability) to achieve our system
design. Such decisions require some intuition and design experience on the
part of the system engineers; however, the foregoing methods provide some
engineering calculations to help guide intuition.
7
.
6
.
6
Availability Apportionment
Up until now, the discussion of apportionment has dealt entirely with system
and subsystem reliabilities. Now, we discuss the question of how to proceed
if system availabilities are to be apportioned. Under certain circumstances, the
subsystem availabilities are essentially independent, and the system availabil-
ity is given by the same formula as for the reliabilities, with the availabili-
ties replacing the reliabilties. A discussion of availability modeling in general,
and a detailed discussion of the circumstances under which such substitutions
are valid appears in Shooman [
1990
, Appendices F]. One situation in which
the availabilities are independent is where each subsystem has its own repair-
man (or repaircrew). This is called repairman decoupling in Shooman [
1990
,
Appendices F-
4
and F-

350
RELIABILITY OPTIMIZATION
the results. We can explore the decoupled approximation again by considering
a slightly different problem than that in Chapter
4
: two series subsystems that
are served by the same repairman. Returning to the results derived in Chapter
3
, we can compute the exact availability using the model given in Fig.
3
.
16
and Eqs. (
3
.
71
a–c). This model holds for two identical elements (series, paral-
lel, and standby). If we want the model to hold for two series subsystems, we
must compute the probability that both elements are good, which is P
s
0
. We
can compute the steady-state solution by letting s 
0
in Eqs. (
3
.
71
a–c), as
was discussed in Chapter

, pp.
344
–
346
]. For ordinary (not
standby) two-element systems, l
′

2
l and m
′

m
′′

m. Substitution yields
A
∞

m
2
2
l
2
+
2
lm + m
2
(
7

.
3
, we see that the ratio of
the approximate unavailability (
1
− A≈) to the exact unavailability (
1
− A

)
approaches unity and is quite acceptable in all the cases shown. Of course,
one might check the validity of the approximation for more complex cases;
however, the results are quite encouraging, and we anticipate that the approx-
imation will be applicable in many cases.
TABLE
7
.
3
Comparison of Exact and Approximate Availability Formulas
Approximate Exact Ratio of
Formula: Formula: Unavailability:
Ratio m
/
l Eq. (
7
.
30
), A ≈ Eq. (
29
b), A

995
OPTIMIZATION AT THE SUBSYSTEM LEVEL VIA ENUMERATION
351
7
.
6
.
7
Nonconstant-Failure Rates
In many cases, the apportionment approaches discussed previously depend on
constant-failure rates (see especially Table
7
.
2
, third row). If the failure rates
vary with time, it is possible that the optimization results will hold only over
a certain time range and therefore must be recomputed for other ranges. The
analyst should consider this approach if nonconstant-failure rates are signifi-
cant. In most cases, detailed information on nonconstant-failure rates will not
be available until late in design, and approximate methods using upper and
lower bounds on failure rates or computations for different ranges assuming
linear variation will be adequate.
7
.
7
OPTIMIZATION AT THE SUBSYSTEM LEVEL VIA
ENUMERATION
7
.
7

1957
;
Bierman,
1969
; Cormen,
1992
; Hiller,
1974
]. The approach used was gener-
ally dynamic programming or greedy methods; these approaches will be briefly
reviewed later in this chapter. This section will discuss a bounded enumeration
approach [Shooman and Marshall,
1993
] that the author proposes as the simplest
and most practical method for redundancy optimization. We begin our develop-
ment by defining the brute force approach of exhaustive enumeration.
7
.
7
.
2
Exhaustive Enumeration
This approach is straightforward, but it represents a brute force approach to
the problem. Suppose we have subsystem i that has five elements and we wish
to improve the subsystem reliabiity to meet the apportioned subsystem goal
R
g
. If practical considerations of cost, weight, or volume limit us to choosing
at most a single parallel subsystem for each of the five elements, each of the
352

Example
1
: The initial design of a system yields
3
subsystems at the first level
of decomposition. The system reliability goal, R
g
, is
0
.
9
for a given number
of operating hours. The initial estimates of the subsystem reliabilities are R
1

0
.
85
, R
2

0
.
5
, and R
3

0
.
3

units and that
13
units are left for redundancy. Thus we
can allocate
0
or
1
or
2
or any number up to
13
parallel units to subsystem
1
, a
similar number to subsystem
2
, and a similar number to subsystem
3
. An upper
bound on the number of states that must be considered would therefore be
14
3

2
,
744
. Not all of these states are possible because some of them violate the
weight constraint; for example, the combination of
13
parallel units for each

, R
2

0
.
8
, R
3

0
.
8
, R
4

0
.
9
, and R
5

0
.
9
. Parallel redundancy is to
be used to improve the initial design so that it meets the reliability goal. The
constraint is cost; the subsystems are assumed to cost
2
,
2

for us to meet the system goal. Lacking further analysis, we can state that the
initial system costs
12
units; thus we can allocate up to
24
cost units to each of
the subsystems. For subsystems
1
,
2
, and
3
, we can allocate
0
or
1
or
2
or any
number up to
12
parallel units. For subsystems
4
and
5
, we can allocate
0
or
1
or

1
Introduction
An analyst is often so charmed by the neatness and beauty of a closed-form
synthesis process that they overlook the utility of an enumeration procedure.
Engineering design is inherently a trial-and-error iterative procedure, and sel-
dom are the parameters known so well that an analyst can stand behind a design
and defend it as the true optimum solution to the problem. In fact, presenting
a designer with a group of good designs rather than a single one is generally
preferable since there may be many ancillary issues to consider in making a
choice. Some of these issues are the following:
•
Sensitivity to variations in the parameters that are only approximately
known.
•
Risk of success for certain state-of-the-art components presently under
design or contemplated.
•
Preferences on the part of the customer. (The old clich
´
e about the “Golden
Rule”—he who has the gold makes the rules—really does apply.)
•
Conflicts between designs that yield high reliability but only moderate
availability (because of repairability problems), and the converse.
•
Effect of maintenance costs on the chosen solution.
•
Difficulty in mathematically including multiple prioritized constraints
(some independent multiple constraints are easy to deal with; these are
discussed below).

Eqs. (
7
.
11
), (
7
.
12
) and (
7
.
13
) allow us to eliminate a large number of combina-
tions that constitute infeasible solutions. These bounds, powerful though they
may be, merely state the obvious—that the reliability of a series of independent
subsystems yields a product of probabilities and, since each probability has an
upper bound of unity, that each subsystem reliability must equal or exceed the
system goal. To be practical, it is impossible to achieve a reliability of
1
for
any subsystem; thus each subsystem reliability must exceed the system goal.
One can easily apply these bounds by enumeration or by solving a logarithmic
equation.
The reliability expression for a chain of k subsystems, where each subsystem
is composed of n
i
parallel elements, is given in Eq. (
7
.
3

solving for the smallest value of n
i
that satisfies Eq. (
7
.
30
). A slightly more
direct method is to solve Eq. (
7
.
30
) in closed form as an equality:
(
1
− r
i
)
n
i

1
− R
g
(
7
.
31
a)
Taking the log of both sides of Eq. (
7

1
of the last section.
Solving Eq. (
7
.
31
b) for Example
1
yields
BOUNDED ENUMERATION APPROACH
355
n
1

log(
1
− R
g
)
/
log(
1
− r
1
)

log(
1
−
0

1
− r
2
)

log(
1
−
0
.
9
)
/
log(
1
−
0
.
5
)

3
.
32
(
7
.
32
b)
n

6
.
46
(
7
.
32
c)
Clearly, the minimum values for n
1
, n
2
, and n
3
from the preceding computa-
tions are
2
,
4
, and
7
, respectively. Thus, these three simple computations have
advanced our design from the original statement of the problem given in Fig.
7
.
4
(a) to the minimum system design given in Fig.
7
.
4

0
.
85
)
2

0
.
9775
(
7
.
34
a)
R
2

1
− (
1
−
0
.
5
)
4

0
.
9375

1
R
2
R
3

0
.
9775
×
0
.
9375
×
0
.
9176

0
.
84089
(
7
.
34
d)
The minimum system design represents the first step toward achieving an
optimized system design. The reliability has been raised from
0
.

cases, a huge decrease from the initial estimate of
2
,
744
cases.
(This number,
64
, will be further reduced once we add the upper bounds of
Section
7
.
8
.
3
.) In fact, because this problem is now reduced, we can easily
enumerate exactly how many cases remain. If we allocate the remaining
3
units to subsystem
1
, no additional units can be allocated to subsystems
2
and
3
because of the cost constraint. We could label this policy n
1

5
, n
2


, and Dn
3

0
, or incremental policy (
3
,
0
,
0
).