Copyright © IF.-\.

C Indu strial Process Control

Systems. Bru ges. Belgium. 1988

AV AILABILITY, RELIABILITY OR
REDUNDANCY ... RELIEVING THE
CONFUSION
K. M. Renner
Illd ustria l S),stems Group ,'vtarketi,lg. Measurex CO/poratio n. One Results Way.
Cupertillo. CA 950[.1. ['SA

lIhstract. Reliability and redundancy are o.u term; used frequently

in discussicns ~ the ability of an in:lustrial process
CCl"ItroI system to witl1stand module or system failure. 'Ihe
~le nature with which these term; are used often
clco:is the real "issue of availability and creates an environment
where expensive decisicns are made, in error, base::l m technical
data of questimable validity. '!his article will differentiate
availability fran reliability and redundancy, eq:ilasize the
ilIportance of the failure definitim, and a.ttline a methodology
for in:lustrial process CCl"ItroI system failure evaluatim.

Keywords. Reliability; Availability; Process Ccntrol systems;

Failure Analysis; Failure Definitim.

nma:ucrICfi While indirectly ackiressin3 the system failure

A process oa'ltrol system IIIJSt perform its
duties c:alSistently, as designed, in order to
maximize the benefit to be achieved frem
investment in its ilIplementatim. 'Ihe advent,
and inc:reasin3ly wide use, of micrq>rooessOr
base::l oa'ltrol syst:aIB, which I"E!I1¥JVe the plant
operator further fran his process, has led to
the growing ~ for the oa'ltrol system
to be "solid." 'Ibat is, it has inherent
characteristics which preserve total system
availability and minimize the jecpardy in
which a plant is placed shalld a oa'ltrol
system failure cxx:ur. 'Ihe process imustry's
increased reliance on automation has
CXI'lSE!Cpf!I'ly increased it's vulnerability to
oa'ltrol system failure. It is probably safe
to assume that availability ilIportance
develqled as an oot:.growth of the space,
ruclear, and military needs for "zero"
downtime in applications which were
miClcptooes&Or oa'ltrolled. While a process
plant is not q.ti.te a space shuttle, the
realizatia'! that extremely reliable syst:aIB
can be develqled has meant that the "solidity
factor' has becc:me a key criteria'! in the
evaluatim of a oa'ltrol system's relative
merits. '!his factor typically manifests
itself in evaluatim of the "abilities"-
availability, reliability, maintainability and
useability. (ref .1)
However, to CXIIIIIJllicate this to prospective
vendors, control system functional
specificatia'\S will often Ca'ltain statements
a'\ly relat1n;J to system redundancy.
e.g.
o "All major oa'ltrol system oc:mpc:nents shall
be made red!.JOOant to avoid any sin3le
failure affec:tin:1 plant operatim or
oa'ltrol."
o "'Ihe oa'ltrol system modules shall be
~iately backed up to ensure a
verifiable up-time of 99.5% minim.lm."
issue, such statements are a means by which
plant persamel feel vemors can be made to
satisfy operatimal requirements - even though
the associated expense may not be justified,
nor, red!.JOOant modules the best SjOlutim.
'Ihe real issue is availability rather than
reliability or redundancy. In fact, selective
redundancy is just a tool used, in certain
awlicatia'\S, to enhance the reliability of
the total module or system. However, enhanced
reliability itself does not necessarily lDIIIIll
enharxled system availability. 'Ihe iDpct of
failure diagrx:sis and repair lIIlSt also be
c:alSidered. It can be shown that aalln:;J
~iate redundancy will not a'\ly have
little positive affect a'! system availability,
rut can actually decrease up-time - often at
significant capital expen:iiture.
'Ihe key to adequately aa:b:'essin3 the oa'ltrol
system availability issue is correct up-fr'alt
definitim and plannirp (ref.2,3) which will
allow the vendor and client to jointly
evaluate redundancy, and other tools, as a
means of eoc:rxmically meetirg the recpired
oa'ltrol system &eO.Irity and integrity.
No analysis of oa'ltrol system availability can
be performed until mdes of failure are
defined and sillplifyin3 asa.m:pt:ia'\S are
documented. It is critical to urDerstand,
fran a process G oa'ltrol perspective, the
aooeptable failure ocn:litia'\S so that the
oa'ltrol system can be designed to eoc:rxmically
meet the result1n;J criteria. As an exzmple,
failure definitim may take the form as
follows:
o No sin3le point of oa'ltrol system failure
shalld inhibit the ability for the plant to
be shutdown safely.

173
174
o UI1sd1eduled plant shutdams due to a
ccntrol system failure shcW.d be limited to
00 IIDre than two per year.
o A plant shut.c:bm is defined as loss of feed
to the plant am product to storage, with
associated trips of eq.dpnent recpi.rirq
greater than two hrurs to retw:n to steady
state cperaticn.
o No sirqle ccntrol system failure shcW.d
prevent the cperatirq persamel fran
aooessirq am evaluatirq plant cperaticnal
status.
o Any ccntrol system failure affectirq plant
cperaticn shcW.d be able to be analyzed am
remedied within two hrurs.
o 0.1rrent am historical plant data shcW.d
rot be lost upcn any ccntrol system
failure.
o '!he CCI1Cept of dooble jec:pardy shcW.d be
ClCI1Sidered in the failure analysis where
persamel or envircnnental safety is at
risk.
SUch a failure definiticn set will allow
detenn:inaticn of the failure !IDdes to be used
in a ccntrol system availability analysis.
Note that it is :inportant to document
qualifyirq assunptic:ns that are made in
derivirq the definiticn set. By looJtirg at a
generic control systeu functicnal flow
architecture (Fig. 1) it is seen that the
serial method by which JOOdule functic:ns are
organized places a reliaJxle cn minimizirq
sirqle points of failure. '!he loss of any
link or fun1amental element in the CXlI1troI
hierarchy will adversely affect system up-
time. Any sirqle element that can fail am
precipitate a plant failure, as defined, is
called a "sirqle point of failure." '!he
reliability and predictability of such
elements will have a marked inpact cn
achievirq high availability.
Few situatic:ns in marufacturirq in::hJstry
require absolutely m sirqle point of failure.
An extreme case walld lead to dual final
elements, transducers, tezminatic:ns, etc.
l'bile this is possible, sirqle failure points
may still exist (e.g. switches fran cn-line to
back-up), am for !IDst applicatic:ns, this is
rot justified.
'!he key issue here is: How do I minimize
failure risk by increasirq the reliability of
the weakest links, thereby increasirq Cl\l'erall
system availability?
To identify which links affect the plant
cperaticn the prime points to ClCI1Sider
include:
o What is defined as a failure?
o can the plant be partiticned ccntrol-w1se
to minimize failure :ilrpact?
o How quickly am cxnveniently can failures
be diagnosed am remeclied?
o What c:pticnal redun:1an::y or bacIoJp ccntrol
system facilities are available shcW.d they
be deemed necessary?
o Is lIXldular cn-line replacement possible?
o Are there critical processes or periods
which req.dre enhaooed ccntrol system
reliability?
o What level of self d.iagnostics are
available cn the ccntrol system?
o can the prooess be ccntrolled JIBIUally in
the event of a ccntrol system failure?
By addressirq such q.JeStitrlS fran hardware,
software and cperaticnal perspectives, a
realistic failure definiticn is OClIPleted,
K. M. Renner
which will prCl\l'ide the basis for the
availability analysis.
HARDolARE ANALYSIS
'!he true a;ntrol system hardware reliability
analysis :lS based upcn the statistical
fun1amentals whereby the probability of a
CXlI1troI system cperatirq withrut failure, for
a specified period of time, is defined as it's
"reliability." Or more succinctly,
"reliability is the probability of survival".
'Ihree CCI1Cepts help to relate reliability am
failure:
o '!he probability of a given system failure
OCOlZTirq is a OCI\i)inaticn of the
individual lIXldule or a::JIt)CXleI1t failure
probabilities.
o '!he failure rate (rn.mi:Jer of failures per
unit time) typically follows the ''bathtub
curve." Le. three distinct failure zcnes
exist ~ a product's life which are
distirgui.shed by failure frequen:y - the
infant IIDrtality zcne, ClCI1Stant zcne, and
the wear-o.rt: zcne.
o A micrc:prooessor based JOOdule, or system,
spen:ls the majority of its life in the
ClCI1Stant zcne.
Therefore, the probability of survival,
(reliability), for a specific period of time,
is related to the failure rate by an
expcnential expressicn: (ref.4)
R = e ~t (1)
where: R = reliability
~ =failure rate (failures/time)
t = specific time period.
am as failure rate is the inverse of
mean time between failure (KI'BF):
MI'BF = 1/~ (2)
am R = e (-t/MI'BF) (3)
This expressicn exenplifies the limited
pragmatic use of the tenn "reliability".
Le. '!he cne year reliability of a system
with a MI'BF of 5 years is 82\.
Inc::reasirq the MI'BF to 10 years gives a
reliability of 90%. In fact, to
increase the reliability to 99\, a
MI'BF of 100 years is required!
Significantly more practical sense is
accomplished by analyzing the system
availability. Le. the total time a system is
in use, and idle rut capable of beirq used .
Availability and \ uptime are syl'lCI'li'IInl.
'Iherefore:
Availability System wime
Systeu uptime + Systeu downtime
or: A= MI'BF
MI'BF + MI'lR (4)
where: A = availability
MI'BF '" the statistical mean time
between failures (time)
MI'lR = Mean Time to Repair - time
req.rlred to retw:n the system
to cperaticn (time).
as: MI'BF = 1/~
ilIplies: A = 1/[1 + ~ x MI'lR] (5)
 .'h ailabilit\ . Reliability or Redu n danC\"
'Ibis inticates that with realistic values of
system failure rate and mean time to repair,
an approximate system availability can be
calall.ated.
'nle failure rate of the system or JOOdule is
calculated simply by adding together
intividual 0CIIpCl"IeI1t failure rates. 'Ibis
approach is based Q'l the ocn;ervative
ClSSUllptiQ'l that all 0CIIpCl"IeI1ts are equally
critical to the functiQ'l of the rodule, and
prcduoes a pessimistic nodule failure rate.
'nle effect of JOOdule failure Q'l the SUCXlE!SS of
the system is then analyzed and a SUCXlE!SS
logic diagram is produced for the cx:rrplete
system.
algebraically;
~m = 1: (~c X ~c') (6)
where:
~m = module failure.rate (10-6
failuresjha.tr)
~c = 0CIIpCl"IeI1t failure rate
~c '= redundant 0CIIpCl"IeI1t failure rate
'Ibis procedure is best illustrated usin;J an
exanple. Figures 2 and 3 represent boo sinple
control system coofiguratioos (System A and
System B). 'nle differeooe between A and B is
the ad:litiQ'l of a redundant central processor
for control JOOdule U and a redundant
CXIIIII.D'licatioos network.
'nle followi.n;J assunptioos are made:
o Failure definitiQ'l yields the follOlrlin;J
failure recpirement.s:
- Loss of CXIIIII.D'licatioos network
- Loss of control module U
- Loss of cpmitors ocnsole U and *2
o I/O card,lterminatiQ'l loss:
- 2 analog ootpJt cards (16 points)
- 1 digital ootpJt card (16 points)
- 1 digital irpJt card (16 points)
- 1 analog irpJt card (64 points)
Hence the system failure rates for A and B can
be calall.ated.
~A = ~ocmnlink + ~contro1U +
(~opcan*l x ~opcan*2)
~B = (~ocmnlink x ~ocmnlink') + (~controU1 x
~lU) + ( ~opcanU x ~opcan*2)
calall.atiQ'l of intividual 0CIIpCl"IeI1t failure
rates requires failure rate data for boal:d
level modules. r:ata is available either fron
the manufacturer or fun:iarnental m::xiels
provided by refeI'el'XX!S such as the U.S.
Military Hambook MIIrHDBK-217D (ref.S). SUCh
models result in failure rate predictioos for
all elect:rati.c CXllpcnents ...nile allowi.n;J for
differences in envircnnent, teqlerature,
quality factor, stress and cx:rrplexity.
Utilizin; this data, failure rates are
calall.ated for first boal:d level (eg. CRJ
boal:d, ur;dem boal:d, serial I/O boal:d) then
unit level (eg. uninterruptable power SlWly,
mic:roc:x:mplter unit, I/O IlIlltiplexer unit,
cpmitor ocnsole unit) cx::tl\XA1E!llts. Orx::e this
data is available, it is a relatively sinple
procedure to OCJli)ine failure rates in a manner
reflectinq the failure definitiQ'l and system
architecture. Table I SUlIIlIarizes the
calall.atiQ'l for systems A and B usin;J
representative failure rate data .
175
Note:
o I/O card failure rates are incluied in the
failure rate of the control module.
o Redurrlant units incl\J:ie the failure rate of
the switdlcNer mechanism (assumes hat-
backup's)
Orx::e the system failure rate is calall.ated,
all that is needed is the Mean Time to Repair
(MI'IR) in order to estimate system hardware
availability •
Ml'IR is a measure of the time taken to
recognize a failure, diagnose, analyze, and
replace/repair to brin;J the system (and hoE!rDe
plant) back to the status it was in prior to
failure. Here, the inportance of the failure
definitiQ'l again is cq:parent. 'nle Ml'IR of the
control system alooe may be just the time to
diagoose and replace a sin;Jle boal:d or
0CIIpCl"IeI1t. Parts may be Q'l site; at a local
service center; or guaranteed 12 hc:ur
delivery; or even installed as warm spares.
System maintainability will enhar¥::e diagmsis
and repair ~le parts delivery is deperdent
upon locatiQ'l. Naturally, m::lSt critical
parts, with higher failure rates, WQlld be
8lCpeCted to be easily and quickly a<DeSSible.
Of more inportance, however, is the inpact the
control system failure has Q'l the cpmitin:.J
plant. If the failure, as defined, leads to a
loss of productiQ'l for 8 hc:urs ~le the plant
is returned to steady state, then the ~
Ml'IR as a result of control system failure
JIIJSt include this. It beoanes cq:parent that a
trade-off develcps between failure definitiQ'l,
failure rate, Ml'IR and maintainability. 'nle
more easily and rapidly a control system can
be repaired and the more quickly the inpact Q'l
the plant is resolved, the less E!IlPJasis needs
to be placed Q'l reductiQ'l in failure rate to
acrueve cx:rrparable availability.
In our exanple, let's assume a Ml'IR of 4 hc:urs
for the failures identified.
'nlen: ~ = 1/[1 + IfiA x ~l
=~
and:
'nle ad:litiQ'l of redundant CXIIIII.D'licatiQ'l links
and primary processor, has increased the
system availability to essentially loot.
If w assume, however, that the control and
I/O for the plant oould be clistrib.rt:ed between
control module U and control rodule '2, in
system A, such that failure of both control
modules WQlld be defined as a failure, then
the availability of system A oould be
increased to essentially 10()\ also, at
minimal, i f any, ad:liticnal e>cpen&e. 'lhe
redundant control module U prtXlEISSOr WQlld
not be neoessazy.
rurther, if the Ml'IR was redooed to 1 hc:ur
!ran 4 hc:urs, a similar ircrease in Systan A
availability results.
lt1ile the hardware analysis can be relatively
objective within the limits of the failure
definition, failure rate accuracy and
assunptiCl'lS made, it will be seen that
q.W.itative and subjective cx::tl\XA1E!llts JIIJSt be
factored to the total availability "ecp!tim".
What this analysis shows is that the
relationships between availability,
reliability, HIm' and Ml'IR shc:W.d be fUlly
understood before any control system
"solidity" specificatim is att.arpted.
176 K.
'!HE SOFlWARE ANALYSIS
All major micrcprocessor based process oart:rol
system; have varyin; levels of software that
is nq.ri.red for suooessful c:peratien. '!be
reliability of such software is an :inp:>rtant
issue in determining control system
availability, however, its true ~ct is
difficult to quantify and often
urxJerestimated.
~ articles have defined methods for
enharx:in; software reliability with III.ldl.
EIIPlasis placed en adherence to rigorrus
structured progranming starDards, correct
plannin;, detailed testin; and substantial
documentation. However, III.ldl. of the
perfoz:manoe data has been derived fraIl
otIIplter ClR'licaticns in data processin;,
office autanatien and transacticnal processin;
which are rtt totally indicative of process
oart:rol system c:peratien. ~ity measurement
has been based en an d:>jective to produce
"software without defects that 1oUJ.l.d cause the
system to step ClCIIl>letely or to produce
unaooeptable results" (ref.6). ~le these
fundamentals are still ClR'licable to process
oart:rol system;, :inp:>rtanoe sha.lld be placed
en the interacti.en of software JOOdules, at
variws levels, within the real time plant
c:peraticnal enviramlent and their ~ct en
plant c:peratien.
Generally, process oart:rol system software can
be divided into foor hierarc:hi.cal levels as
shown in Figure 4.
o Microoode is the basic micrcprocessor chip
level machine instructien set (eg. Intel
8086)
o OperatiIp svstEm is the CFU system
software. (eg. IR: \'MS)
o Real Tllne Q:lntrol Code is the real time
system software which facilitates on-line
process oart:rol and sharin; of system
resources.
o Arplicatioos Code is user (or vermr)
written software specific to the process
oart:rol ClR'licatien.
As ale progresses fraIl level I t.hrcu:Jh level
IV the followin:] ClR'lies:
o Software c:peraticnal history decreases
o N\.mi)er of ClR'licaticns decreases
o Testin;J time decreases
o F'l:'eI:peB:y of changes and 1IIXiificaticns
iJx:reases
o N\.mi)er of unfoun:1 ''J:u;Js'' in::reases
'!his ilIplies that overall software reliability
decreases durin; the progressien to ..mere the
applicaticns code is the rost vulnerable.
'!his is :inp:>rtant in the plant oart:rol
envircnDent because it is the real time
oart:rol and ClR'licatien software which is rost
aooessible to the user and rost critical to
the plant c:peratien. "Software which ~ is
liJce a car which ~ • • • it is best left
alale." However, differin; ClR'licaticns and
typical plant changes require that
mdificaticns be made, and rost frequently at
levels III and IV. SUbjectively, changes may
hardly ever be made to proven microcode, while
c:harx]es may be made yearly to the c:peratin;
system, JIalthly to a oart:rol system source
code and even daily to ClR'licaticns code. '!be
ease and sillplicity with which such changes
can be made by a user, (especially at the
~I . Re nner
ClR'licaticns level), will play a large role in
oart:rol system availability. '!be ability to
fully test is often rtt ClR'rcpriate in an on-
line oart:rol system hen::e quality 1Il.Ist be
designed-in and built-in to the software.
Of eq.Jal :inp:>rtanoe is the possibility of
changes made in ale level of software
affectin; the reliability of an::Jt:her level.
An extreme case 1oUJ.l.d be software 'fixes' made
in ale level, as a result of a 'b.Jg' in
an::Jt:her level, which is later updated with a
software 'patch' that contaminates the
original 'fix'. '1hese issues are rtt trivial
and require ilIplementatien of strict software
develc:pnent, c:peration and dlange starDards.
In fact, prd:>lems such as these are III.ldl. of
the drivin; force behind Fm otIIplter oart:rol
system validation requirements in the
Fhannaceutical in:lustry. Not only 1Il.Ist the
software ~ct be evaluated, but also the
~ct on plant c:peration and pro:luct quality.
Requirements liJce these separate the on-line
control system fraIl the mainframe data
processin; otIIplter.
Generally, in redundant processors, ~ies of
the sarre software will be runnin;; hen::e if a
software fault occurs in the on-line
processor, there is a good dlaJy:,e the sarre
fault will occur upon swit.c:halrer to the
backup. '!his places EIIPlasis on the
requirement, for both software and hardware,
that redundant systems be adequately exercised
to ensure their integrity.
'!be ClCIIl>lexity of the software reliability
issue and the factors influerx:in; it, result
in a detailed, objective, software
availability analysis bein; practically
inpossible to perfonn. Any results 1oUJ.l.d be
amitrary and assume wide limits of error. In
the process control system. ClR'lication,
software reliability is typically addressed
indirectly by ClR'lyin; rigid c:peration,
documentation and security starDards. In
appl ications where substantial software
develc:pnent is a necessity, a dedicated seni-
offline develqment and testin; system is
often used thereby reducin; a major source of
on-line oart:rol system failure potential.
The crucial analysis, however, is the
relationship between software failure and the
overall oart:rol system failure definition. It
is often difficult, early in a control system
project, to predict the software that will be
runnin; and what it will be doin; - especially
at the ClR'licaticns code level. '!be software
that is predictable and can be analyzed (ie.
levels I, ll, and Ill) sha.lld be evaluated
for:
o ~ticnal history
o OX:umentatien
o ~ity testin; procedures
o Failure modes
o Redun::lant ~rtunities
As ClR'lication specific software is develcped
it sha.lld be rigorrusly tested and doaJmented,
if possible, prior to on-line c:peratien.
Features such as a "DIy Run" mode enhance the
probability of removin; ''J:u;Js'' without
jeopardizin; plant c:peratien. Every effort
shoold be made to produce software modules
which, cnoe proven, can be used in repeatable
ClR'licaticns .
Reliability and redI.In::lan:y, as ClR'lied to
software, are therefore tenns which require
 :h ailability, Reliabilit\, or Red u nd ancy 177

fUn:Jamental analysis, however, the nature of
software and the tools available, determine
that arrt analysis is largely subjective.
Practical ilrprovements to software reliability
are limite:i to the ecan::mic and organizaticnal.
effort recpired to create and enforce detailed
deYel.q:ment, t.esti.n;J and qJeratial standards.
'!he susoeptibility of the OCI'ltrol system due
to software failure is best evaluate:i al this
basis.
Develq:ment of a process OCI'ltrol system
specificatial by the iroustrial user is often
anticipate:i with fear. By urrlerstand.irg the
key qJeraticnal. factors associate:i with a
OCI'ltrol system for his plant, Il'l.Idl. of the
cq:prehensial can be eliminate:i. In this
respect, control system availability
requirements must be defined with an
cq:preciatial of the relative iIIpacts of
reliabili ty (both hardware and software) and
maintainability •
Prior to arrt analysis of availability, a
failure definitial DIJSt be resolved anr:rgst
plant eI'X1ineerirq and qJeratirq persamel .
nlls definitial fonns the basis for evaluatirq
the OCI'ltrol system architecture for ~imJm
process uptime. (Figure 5).
'!he ad:litial of redundant ~ is a
CXIIIID'l cq:proach taken to enhancirq OCl'ltrol
system availability. While generally
SllCXlE!SSful, careful evaluatial of econcmic and
qJeraticnal. justificatial shoold precede such
a decisial. LimitatialS which can often
detract fran backup systems (both hot and
warm) shcW.d be recognized. Any redundant
carp::I'leJlt shoold be pericxlically mc.ni.tored for
health while in backup 1OOde. In practice,
most redundant systems are subject to CXIIIID'l
IOOde failures which limit the potential
availabili ty. such failures are not
necessarily hardware faults, but can be
relate:i to qJeratirq ernrircrrnent, software
prci>lems or maintenance procedures.
By relievi1q the oc:nfusial associate:i with the
terms availability, reliability, and
redundan:::y and stressirq the need for thorc:u:Jh
failure definitial, the fc:mrlatial exists for
joint userjven:Jor develq:ment of process
OCl'ltrol system architectures to meet specific
plant requirements for SE!alrity, integrity and
safety .
1. ~ity Ccrttrol Harrlbook. (1951). '!he
Abilities. M:&raw--Hill.
2. Renner, KeYyn M. (1985). Develq:ment of an
Autanatial Plan for a Rlannaoeutical
Manlfacturirq Plant. Hlarmaoeutical
Tgfulology .
3. Renner, KeYyn M. (1987). Management
strategy . for ~lannirq Plant Autanatial.
Food Ernl1lgeI'llP·
4. Hamilton, Paul R. (1987) . Reliability,
Availability, and Fault Tolerance.
~.
5 . Department of Defense Militazy Harrlbook,
2170. (1982). Reliability Prediction of
Electrcru.c Equiprent.
6. Jones, T. capers. (1986). Progran1tIirg
Productivity. l'tGraw--Hill.

System Failure Rate ExaItple

M::xlule ~

~U 24.0
576 x 10-6 576 x 10-6

~*2 24.0

CcmnL.i.nk 0.25
0.25 6.25 x 10-8

CcmnL.i.nk ' 0.25

CcrttrolU 116.2
116.2 1.51 x 10-2

Ccrttrol U' 130.0

Total System Hardwre

Failure Rates: 116.45 0.0157

q; = Failure rate (10-6 failuresjhc:ur).

178 K. M. Renner

Operator
~ce

-- tIona Network

~viaory
PrOC888Ol'

RegUatory
Procesaor

VO
Termlnatlone

VP Converter.
Tranerrittera

FIl8I Control
EJementa

Fig. 1. CONTROL SYSlEM FUNCTIONAL HIERARCHY

 Availability, Reliability or Redundancy 179

Oper&to.. Operato..
Coneole 11 Coneole 12

o • I I -0
I I
Control Control
Koclule 12

.
Koclule 11

•n
• ,• ,•
a j~ j~
n 1r 1r ,
"etd I/O "etd I/o

Fig. 2. System A Architecture

Operato.. Operato..
CoDeole 11 Coneole 12

Control Control
Koclule 11 Koclule 12

"etd I/O "etd I/O

Fig. 3. System B Architecture

180 K. M. Renner

Ft,. 11 . EvaluaUIlI Control System Availability