nureg/cr-6303, 'method for performing diversity and ... · nureg/cr-6303 ucrl-id-119239 method...

NUREG/CR-6303UCRL-ID-119239

-Method for Performing Diversityand Defense-in-Depth Analysesof Reactor Protection Systems

Prepared by

Prepared byG. G. Preckshot

Lawrence Livermore National Laboratory

Prepared forU.S. Nuclear Regulatory Commission

AVAILABILITY NOTICE

Availability of Reference Materials Cited in NRC Publications

Most documents cited In NRC publications will be available from one of the following sources:

1. The NRC Public Document Room, 2120 L Street, NW., Lower Level, Washington, DC 20555-0001

2. The Superintendent of Documents, U.S. Government Printing Office, P. 0. Box 37082, Washington, DC

20402-9328

3. The National Technical Information Service, Springfield, VA 22161-0002

Although the listing that follows represents the majority of documents cited In NRC publications, It Is not In-tended to be exhaustive.

Referenced documents available for Inspection and copying for a fee from the NRC Public Document Room

Include NRC correspondence and internal NRC memoranda; NRC bulletins, circulars, Information notices, In-spection and Investigation notices; licensee event reports; vendor reports and correspondence; Commissionpapers; and applicant and licensee documents and correspondence.

The following documents In the NUREG series are available for purchase from the Government Printing Office:formal NRC staff and contractor reports, NRC-sponsored conference proceedings, International agreementreports; grantee reports, and NRC booklets and brochures. Also available are regulatory guides, NRC regula-tions In the Code of Federal Regulations, and Nuclear Regulatory Commission Issuances.

Documents available from the National Technical Information Service Include NUREG-serles reports and tech-nical reports prepared by other Federal agencies and reports prepared by the Atomic Energy Commission,

forerunner agency. to the Nuclear Regulatory Commission.

Documents available from public and special technical libraries Include all open literature Items, such as books,

journal articles, and transactions. Federal Register notices, Federal and State legislation, and congressionalreports can usually be obtained from these libraries.

Documents such as theses, dissertations, foreign reports and translations, and non-NRC conference pro-ceedings are available for purchase from the organization sponsoring the publication cited.

Single copies of NRC draft reports are available free, to the extent of supply, upon written request to the Officeof Administration, Distribution and Mail Services Section, U.S. Nuclear Regulatory Commission, Washington,DC 20555-0001.

Copies of Industry codes and standards used In a substantive manner In the NRC regulatory process are main-tained at the NRC Library, Two White Flint North, 11545 Rockvllle Pike, Rockville, MD 20852-2738, for use bythe public. Codes and standards are usually copyrighted and may be purchased from the originating organiza-tion or, If they are American National Standards, from the American National Standards Institute, 1430 Broad-way, New York, NY 10018-3308.

DISCLAIMER NOTICE

This report was prepared as an account of work sponsored by an agency of the United- States Government.Neitherthe United States Government norany agencythereof, norany of their employees, makes anywarranty,expressed or implied, or assumes any legal liability or responsibility for any third party's use, or the results of

such use, of any information, apparatus, product, or process disclosed in this report, or represents that its useby such third party would not infringe privately owned rights.

NUREG/CR-6303UCRL-ID-119239

Method for Performing Diversityand Defense-in-Depth Analysesof Reactor Protection Systems

Manuscript Completed: December 1994Date Published: December 1994

Prepared byG. G. Preckshot

Lawrence Livermore National LaboratoryUniversity of CaliforniaLivermore, CA 94551

Prepared forDivision of Reactor Controls and Human FactorsOffice of Nuclear Reactor RegulationU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001NRC Job Code L1867

ABSTRACT

The purpose of this NUREG is to describe a method for analyzing computer-based nuclear reactor protection systems thatdiscovers design vulnerabilities to common-mode failure. The potential for common-mode failure has become an importantissue as the software content of protection systems has increased. This potential was not present in earlier analog protectionsystems because it could usually be assumed that common-mode failure, if it did occur, was due to slow processes such ascorrosion or premature wear-out. This assumption is no longer true for systems containing software. It is the purpose of theanalysis method described here to determine points of a design for which credible common-mode failures are uncompensatedeither by diversity or defense-in-depth.

iii NUREG/CR-6303

CONTENTS

1. Introduction ............................................................................................................................................................................. 11.1. Purpose of this NUREG ............................................................................................................................................... 11.2. W hen to Perform This Analysis ..................................................................................................................................... 11.3. History .......................................................................................................................................................................... 11.4. Goals, January 1994 ...................................................................................................................................................... 11.5. Philosophy Behind the Analysis .................................................................................................................................... 21.6. Overview of Contents .................................................................................................................................................... 2

2. Definitions .............................................................................................................................................................................. 22.1. Defense-in-Depth ......................................................................................................................................................... 22.2. Echelons of Defense ....................................................................................................................................................... 2

2.2.1. Control System .................................................................................................................................................. 22.2.2. Reactor Trip or Scram System .......................................................................................................................... 22.2.3. ESF Actuation System ...................................................................................................................................... 22.2.4. M onitoring and Indicator System ...................................................................................................................... 3

2 .3 . C h a n n e l .......................................................................................................................................................................... 32.4. Instrumentation System ................................................................................................................................................. 32 .5 . B lo c k ............................................................................................................................................................................. 32 .6 . D ive rsity ........................................................................................................................................................................ 3

2.6.1. Human Diversity ............................................................................................................................................... 32.6.2. Design Diversity ............. : ................................................................................................................................ 32.6.3. Software Diversity ........................................................................................... 42.6.4. Functional Diversity .......................................................................................................................................... 42.6.5. Signal Diversity ................................................................................................................................................. 42.6.6. Equipment Diversity ........................................... : ................................................ ' .............................................. 4

2.7. Com mon-M ode (or -Cause) Failure .............................................................................................................................. 42.8. Anticipated Operational Occurrences ........................................................................................................................... 42.9. Accidents ....................................................................................................................................................................... 5

3. Analysis Guidelines ................................................................................................................................................................. 53.1. G uideline ---Choosing Blocks .................................................................................................................................... 53.2. G uideline 2- Determ ining Diversity ............................................................................................................................ 6

3.2.1. Design Diversity ............................................................................................................................................... 73.2.2. Equipment Diversity .......................................................................................................................................... 73.2.3. Functional Diversity .......................................................................................................................................... 73.2.4. Human Diversity ....................................................................................................................................3D.......... 73.2.5. Signal Diversity ................................................................................................................................................. 73.2.6. Software Diversity ............................................................................................................................................. 83.2.7. Combining Diversity Attributes ........................................................................................................................ 8

3.3. Guideline 3- System Failure Types ............................................................................................................................. 83.3.1. Type I Failures ......................................................... I ........................................................................................ 83.3.2. Type 2 Failures .................................................................................................................................................. 83.3.3. Type 3 Failures .................................................................................................................................................. 9

3.4. G uideline 4- Echelon Requirem ent ............................................................................................................................. 93.5. G uideline 5- M ethod of Evaluation ........................................................................................................................3.6. G uideline 6- Postulated Com mon-M ode Failure of Blocks .................................................................................. 93.7. G uideline 7- Use of Identical Hardware and Software M odules ......................................................................... 103.8. Guideline 8- Effect of Other Blocks .......................................................................................................................... 103.9. G uideline 9- Output Signals ...................................................................................................................................... 103.10. Guideline 10- Diversity for Anticipated Operational Occurrences ..................................................................... 103.11. Guideline 11 -- Diversity for Accidents .............................................................................................. 10

v NUREG/CR-6303

3.12. G uideline 12- Diversity Among Echelons of Defense ....................... I ................................................................ 103.13. G uideline 13- Plant M onitoring .............................................................................................................................. 113.14. Guideline 14- M anual Operator Action ................................................................................................................... 11

4. Data Required to Do the Analysis ......................................................................................................................................... 124.1. System Diagram and Logic Diagram s ........................................................................................................................ 124.2. Chapter 15 Events ....................................................................................................................................................... 124.3. Alternate Trips ............................................................................................................................................................ 124.4. Req uired M itigation .................................................................................................... : ............................................... 12

5. W hat Should be in an Analysis? ............................................................................................................................................ 12

6. Assumptions to be Stated ...................................................................................................................................................... 146.1. W orst-Case Assumptions ............................................................................................................................................ 146.2. Assumptions.Based on System Structure .................................................................................................................... 14

6.2. 1. Diversity of Blocks ......................................................................................................................................... 156.3. Assum ptions for Echelon .................................................................................................................. .......................... 156.4. Evaluation Criteria .................................................................................................................................. 16

7. Description of the Design ...................................................................................................................................................... 167.1. Design Basis ................................................................................................................................................................ 16

7. 1. 1. General or Regulatory Bases ........................................................................................................................... 167.1.2. Additional Agreed Bases ................................................................................................................................. 177.1.3. Applicant's Statements ..................................................................................................................................... 17

7.2. Design Architecture .................................................................................................................................................... 177.3. Intentional Design Diversity ...................................................................................................................................... 17

8. Findings ................................................................................................................................................................................. 188.1. General Vulnerabilities ............................................................................................................................................... 188.2. Specific Vulnerabilities ............................................................................................................................................... 188.3. Evaluation of Diversity ............................................................................................................................................... 188.4. Shared Signals ............................................................................................................................................................. 188.5. Special Findings .......................................................................................................................................................... 18

9. Aids to Presentation or Analysis ........................................................................................................................................... 189. 1. Analysis Charts ........................................................................................................................................................... 189.2. System Block Diagram ................................................................................................................................................ 189.3. Vulnerability Sum m ary Charts ................................................................................................................................... 19

References ................................................................................................................................................................................... 27Appendix- Block Exam ples ...................................................................................................................................................... 29

FIGURES

Figure 1. Pressurized W ater Reactor Analysis Chart ................................................................................................................ 20Figure 2. Boiling W ater Reactor Analysis Chart ...................................................................................................................... 21Figure 3. Use of Analysis Charts .............................................................................................................................................. 22Figure 4. Sample Pressurized W ater Reactor Vulnerability Sum m ary Chart ....................................................................... 23Figure 5. Sample Boiling W ater Reactor Vulnerability Sum m ary Chart .............................................................................. 24Figure 6. Sum m ary Chart for Analysis of Type 3 Failures .................................................................................................. 25Figure A-I. Sample BW R System Block Diagram .................................................................................................................. 30Figure A-2. Sam ple PW R System Block Diagram ................................................................................................................... 34

NUREG/CR-6303 vi

ACKNOWLEDGMENTS

Some work from NUREG-0493, dated March 1979, has been included verbatim or slightly modified without specificacknowledgment. Some work from references (Palomar et al. 1993a, Palomar et al. 1993b, Preckshot 1993a) has beenincluded without specific acknowledgment. The author thanks and acknowledges previous workers in this area. One person inparticular, Joseph P. Joyce of the Nuclear Regulatory Commission Staff, was both involved in the original NUREG-0493work, and has been directly involved and has guided the work described herein. Mr. Joyce provided continuity and foresightthat might otherwise be lacking. The author also thanks and acknowledges the efforts of other Nuclear RegulatoryCommission staff members who reviewed this work and provided their insights and comments. These gentlemen are Mr.John Gallagher and Mr. Matthew Chiramal. The presentation of this document is due in considerable part to the efforts of Ms.Karen McWilliams.

vii NUREG/CR-6303

Section 1. Introduction

METHOD FOR PERFORMING DIVERSITY

AND DEFENSE-IN-DEPTH ANALYSES OF

REACTOR PROTECTION SYSTEMS

1. INTRODUCTION

1.1. Purpose of this NUREG

The purpose of this NUREG is to describe a method foranalyzing computer-based nuclear reactor protectionsystems that discovers and identifies design vulnerabilitiesto common-mode failure. The potential for common-modefailure has become an important issue as the softwarecontent of protection systems has increased. This potentialwas not present in earlier analog protection systemsbecause it could usually be assumed that common-modefailure, if it did occur, was due to slow processes such ascorrosion or premature wear-out. This assumption is nolonger true for systems containing software. It is thepurpose of the analysis method described here to postulatecommon-mode failures and to determine what portions of adesign are uncompensated either by diversity or defense-in-depth.

In a series of documents, staff concerns regarding digitalcomputers in advanced reactor systems were set forth inSECY 91-292, and an initial statement of a four-pointdiversity and defense-in-depth requirement was made inSECY 93-087. In a staff requirements memorandum (SRM)dated July 21, 1993, the full Commission approved themodified four-point requirement stated below.

1. The applicant shall assess the defense-in-depth anddiversity of the proposed instrumentation and controlsystem to demonstrate that vulnerabilities to common-mode failures have been adequately addressed.

2. In performing the assessment, the vendor or applicantshall analyze each postulated common-mode failure foreach event that is evaluated in the accident analysissection of the safety analysis report (SAR) using best-estimate (using realistic assumptions) methods. Thevendor or applicant shall demonstrate adequatediversity within the design for each of these events.

3. If a postulated common-mode failure could disable asafety function, then a diverse means, with adocumented basis that the diverse means is unlikely tobe subject to the same common mode failure, shall berequired to perform either the same function or adifferent function. The diverse or different functionmay be performed by a non-safety system if the systemis of sufficient quality to perform the necessaryfunction under the associated event conditions.

4. A set of displays and controls located in the maincontrol room shall be provided for manual system-levelactuation of critical safety functions and monitoring ofparameters that support the safety functions. Thedisplays and controls shall be independent and diversefrom the safety computer system identified in items Iand 3 above.

With regard to the first three points, NRC staff considersthat software design errors are a credible source ofcommon-mode failures. Diverse digital or non-digitalsystems are acceptable means of compensating for suchfailures, as is manual action it sufficient time andinformation are available to operators.

1.2. When to Perform This Analysis

Diversity and defense-in-depth analyses should beperformed when a credible potential exists for common-mode failure. This is presently the case for computer-basedsafety systems and would be the case for new-technologysafety systems whose reliability properties are imperfectlyknown. The analysis technique can be used to demonstrateadequate diversity and defense-in-depth, or used as aconstructive design technique to add diverse protectionschemes or equipment to counteract common-mode failurevulnerabilities.

1.3. History

NUREG-0493, "A Defense-in-Depth and DiversityAssessment of the RESAR-414 Integrated ProtectionSystem," published March 1979, was an assessment of asingle reactor protection system that addressed common-mode failure concerns and introduced a method of analysis.Although the application was specific, the 1979 workestablished sufficiently general principles that it wasadapted to analyze the GE ABWR in 1991, theWestinghouse AP-600 in 1993, and the GE SBWR in 1993by an independent NRC contractor. ABB CombustionEngineering used the principles themselves in 1992 toanalyze their System 80+ protection system.

1.4. Goals,.January 1994

Experience applying NUREG-0493 to four other vendor'sprotection systems has led to a clearer picture of how to dothe analysis. In parallel, NRC staff has clarified itstechnical position and obtained Commission approval ofthe four-point diversity and defense-in-depth requirement.

I NUREG/CR-6303

Section 2. Definitions

NUREG-0493 is rewritten here to capture that experience,to explain the techniques for performing the analysis, toremove those details specific to the RESAR-414, and toreflect the technical po•sition of the staff and theCommission.

1.5. Philosophy Behind the Analysis

Analyses performed using the methods of this NUREG arenot intended to require the inclusion or exclusion ofspecific failures in a reactor protection system design basis,but are intended to determine points of vulnerability in adesign to common-mode failures, should they occur. Forthis reason, the choice of credible failures should err on theliberal side of interpretation, and the decision of whether ornot to compensate for discovered vulnerabilities should bemade after this analysis is complete. Accordingly, many ofthe examples presented herein show apparentvulnerabilities, which were either later determined to bedue to insufficient or inaccurate design information, orwere compensated by design modifications.

Modern computer-based systems have become sufficientlycomplex that details can soon overwhelm the analyst.Dividing the system into blocks is intended to reducedesign detail to the abstraction level consistent with thegoals of the analysis. Consequently, the failures postulatedherein subsume many kinds of similar, individual failuresand must be considered group failures whose innerworkings need not be defined precisely. This is typical ofthe effects of software failures in which many individualfailures are capable of producing the same or similaroutputs. Attempting to postulate all possible individualsoftware errors is impossible on any relevant human timescale and is unnecessary.

1.6. Overview of Contents

The balance of this document includes definitions, analysisguidelines, six sections on applying the guidelines andgenerating a documented analysis, and an appendixdemonstrating two different reactor protection systems re-drawn as connected blocks. The application sections dealwith data required, suggested report contents, statement ofanalysis assumptions, design descriptions at appropriatelevels of detail, analysis findings, and graphical aids. Threepublished analyses in the style recommended by thisdocument are noted in the references for those wishing tosee complete examples.

2. DEFINITIONS

2.1. Defense-in-Depth

Defense-in-depth is a principle of long standing for thedesign, construction and operation of nuclear reactors, andmay be thought of as requiring a concentric arrangement ofprotective barriers or means, all of which must be breachedbefore a hazardous material or dangerous energy canadversely affect human beings or the environment. The

classic three physical barriers to radiation release in areactor--cladding, reactor pressure vessel, andcontainment-are an example of defense-in-depth.

2.2. Echelons of Defense

"Echelons of defense" are specific applications of theprinciple of defense-in-depth to the arrangement ofinstrumentation and control systems attached to a nuclearreactor for the purpose of operating the reactor or shutting itdown and cooling it. Specifically, the echelons are thecontrol system, the reactor trip or scram system, theEngineered Safely Features Actuation System (ESFAS),and the monitoring and indicator system. The echelons maybe considered to be concentrically arranged in that whenthe control system fails, the reactor trip system shuts downreactivity; when both the control system and the reactor tripsystem fail, the ESFAS continues to support the physicalbarriers to radiological release by cooling the fuel, thusallowing time for other measures to be taken by reactoroperators to reduce reactivity. All four echelons dependupon sensors to determine when to perform their functions,and a serious safety concern is to ensure that no more thanone echelon is disabled by a common sensor failure or itsdirect consequences.

2.2.1. Control System

The control echelon is that non-Class IE manual orautomatic equipment which routinely prevents reactorexcursions toward unsafe regimes of operation and isgenerally used to operate the reactor in the safe powerproduction operating region. Indicators, annunciators, andalarms may be included in the control echelon. Reactorcontrol systems typically contain some equipment to satisfythe ATWS rule (10 CFR 50.62) or the requirement for aremote shutdown panel. Examples of such equipmentinclude high-quality non-Class IE equipment for whichcredit may be taken solely for compensating rare common-mode failures of Class IE reactor protection equipment (seepoint 3 of the diversity and defense-in-depth requirement,presented above).

2.2.2. Reactor Trip or Scram System

The reactor trip echelon is that safety equipment designedto reduce reactivity rapidly in response to an uncontrolledexcursion. It consists of instrumentation for detectingpotential or actual excursions, means for rapidly andcompletely inserting the reactor control rods, and may alsoinclude certain chemical neutron moderation systems (e.g.,boron injection).

2.2.3. ESF Actuation System

The ESFAS echelon is that safety equipment whichremoves heat or otherwise assists in maintaining theintegrity of the three physical barriers to radioactive release(cladding, vessel, and containment). This echelon detectsthe need for and performs such functions as emergencycooling, pressure relief or depressurization, isolation, and

NUREG/CR-63032 2

control of various support systems (e.g., emergencygenerators) or devices (valves, motors, pumps) required forESF equipment to operate.

2.2.4. Monitoring and Indicator System

The monitoring and indication echelon is the slowest andalso the most flexible echelon of defense. Like the otherthree echelons, operators are dependent upon accuratesensor information to perform their tasks, but, giveninformation, time, and means, can perform previouslyunspecified logical computations to react to unexpectedevents. The monitoring and indication echelon includesboth Class IE and non-Class lE manual controls, monitors,and indicators required to operate equipment nominallyassigned to the other three echelons.

2.3. Channel

A channel is defined as a set of interconnected hardwareand software, components that processes an identifiablesensor signal to produce a single protective action signal ina single division when required by a generating stationcondition. A channel includes the sensor, data acquisition,signal conditioning, data transmission, bypasses, and logicup to voters or actuating device inputs. The objective of thechannel definition is to define subsets of a reactorprotection system that can be unambiguously tested oranalyzed from input to output.

2.4. Instrumentation System

A plant instrumentation systcm is that equipment whichsenses various plant parameters and trans mits appropriatesignals to control systems, to the reactor trip system, to theengineered safety features actuation sy Istem, and to themonitoring and indicator system for use in determining theactions these systems or reactor operators will take.Independence is required between control systems, safety-related monitoring and display systems, the safety systems,and between redundant divisions of the safety systems.

2.5. Block

Generally, a system is described as an arrangement of"components or black boxes interconnected bycommunication, electrical connections, pipes, or physicaleffects. This kind of description, often called a "systemarchitecture," may be too complex or may not bepartitioned conveniently for diversity and defense- in-depthanalysis. A more convenient description may be obtainedby restricting the portion of the system under considerationto instrumentation and control equipment and partitioningthe restricted portion into "blocks." A "block" is thesmallest portion of the system under analysis for which itcan be credibly assumed that internal failures, including theeffects of software errors, will not propagate to otherequipment. The objective of choosing blocks is to reducethe need for detailed examination of internal failuremechanisms while examining system behavior underreasonable assumptions of failure containment.


Examples of typical software-containing blocks arecomputers, local area networks or multiplexers, orprogrammable logic controllers (PLCs). A block can besolely hardware, but there are no solely software blocks;software-containing blocks suffer the distinction that bothhardware or software faults (and sometimes both actingtogether) can cause block failure. Consequently, it isdifficult to separate the effects of software from themachine that executes that software. For example, asoftware defect in one small routine can cause an entirecomputer to fail by corruption of other data or software.Guideline I and Guidelines 6 through 9 (Section 3) provideadditional direction on-block choice and failure propagationlimits.

2.6. Diversity

Di versity is a principle in instrumentation systems ofsensing different parameters, using different technologies,using different logic or algorithms, or using differentactuation means to provide several ways of detecting andresponding to a significant event. Diversity iscomplementary to the principle of defense-in-depth andincreases the chances that defenses at a particular level ordepth will be actuated when needed. Defenses at differentlevels of depth may also be diverse from each other. Thereare six important types of diversity to consider: humandiversity, design diversity, software diversity, functionaldiversity, signal diversity, and equipment diversity. Anextended discussion of diversity is given in Guideline 2(Section 3.2).

2.6.1. Human D~iversity

The effect of human beings on the design, development,installation, operation, and maintenance of safety systems isknown to be extremely variable, and has been a factor inseveral serious accidents. Used in a positive way, humandiversity can be a plus for system safety. For instance,using different maintenance personnel to calibrate separate,redundant divisions of safety instrumentation may providesome assurance that the same, systematic error is not madein all divisions. Using separate designers to designfunctionally diverse safety systems may reduce thepossibility of similar design errors.

2.6.2. Design Diversity

Design diversity is the use of different approaches,including both software and hardware, to solve the same orsimilar problem. Software diversity is a special case ofdesign diversity and is mentioned. separately because of itspotential importance and its potential defects. The rationalefor design diversity is that different designs will havedifferent failure modes and will not be susceptible to thesame common influences. A factor that weakens thisargumnent is that different designs may nonetheless usesimilar elements or approaches.

3 3 NUREG/CR-6303


2.6.3. Software Diversity

Software diversity is the use of different programs designedand implemented by different development groups withdifferent key personnel to accomplish the same safetygoals-for example, using two separately designedprograms to compute when a reactor should be tripped. Ithas been suggested that sufficient diversity can be obtainedby implementing the same specification throughintentionally diverse designs (possibly by the sameprogramming team); however, the bulk of significantreported experience concerns independent software teams(Kelly et al. 1991). The great hope of software diversity isthat different programmers will make different mistakes.Unfortunately, some (very sparse) data suggest thatdifferent programmers designing to the same requirementstoo often make similar mistakes (Knight and Leveson1986).

2.6.4. Functional Diversity

Two systems are functionally diverse if they performdifferent physical functions though they may haveoverlapping safety effects. For example, cooling systemsnormally intended to function when containment is isolatedare functionally different from other liquid control systemsintended to inject coolant or borated water for otherreasons. However, the other liquid control systems mayhave a useful cooling effect, while the isolation coolingsystems may have useful coolant makeup side effects.Functional diversity is often useful when determining ifsufficient mitigation means have been employed in apostulated accident; a combination of alternative systems inthe face of primary system failure may be enough tomitigate the effects of an accident.

A type of functional diversity, called "aspect" diversity,was applied to systems using relays, specifically todistinguish "de-energize to trip" arrangements from"energize to trip" arrangements. Subsequent experience(Hanauer 1990) has shown that this is less effective--evenin relay systems-than originally supposed. In digitalsystems, aspect diversity can be implemented by a trivialinterposition of one logical negation instruction, whichrenders claims of aspect diversity even more suspect. Someadvantage may be claimed by the use of "watchdog" timersor watchdog processors, but experience has shown that

these, too, are difficult to implement reliably (Mahmoodand McCluskey 1988).

2.6.5. Signal Diversity

Signal diversity is the use of different sensed parameters toinitiate protective action, in which any of the parametersmay independently indicate an abnormal condition, even ifthe other parameters fail to be sensed correctly. Forexample, in a BWR, neutron flux increase due to voidreduction is a diverse parameter to reactor pressureexcursion for events that cause a reactor pressure pulse.

2.6.6. Equipment Diversity

Equipment diversity is the use of different equipment toperform similar safety functions, in which "different"means sufficiently unlike as to significantly decreasevulnerability to common failure. The fact that equipment ismade by different manufacturers does not guaranteediversity; many computer designs use the samesemiconductor chips, and in the most extreme cases, twosuppliers may acquire, re-label, and sell the same printedcircuit boards from a single manufacturer. The use ofdiverse computer equipment may have an effect onsoftware diversity; using a different computer architectureforces the use of diverse compilers, linkers, and othersupport software.

2.7. Common-Mode (or -Cause) Failure

Common-mode failures (CMFs) are causally relatedfailures of redundant or separate equipment. For example,(1) A CMF of identical subsystems across redundantdivisions defeats the purpose of redundancy, or (2) A CMFof different subsystems or echelons of defense defeats theuse of defense-in-depth. CMF embraces all causal relations,including severe environments, design errors, calibrationand maintenance errors, and consequential failures.Common-mode failure is further elaborated in Guideline 3,and discussed in detail with respect to rules for postulatingit in Guideline 6.

2.8. Anticipated Operational Occurrences

For the purposes of the analysis described in this document,a basis set of anticipated operational occurrences should beidentified by the following criteria.

NUREG/CR-6303 4

Section 3. Guidelines

"'Anticipated operational occurrences' mean thoseconditions of normal operation which are expectedto occur one or more times during the life of thenuclear power unit and include but are not limited toloss of the turbine generator set, isolation of the maincondenser and loss of offsite power" (10 CFR 50,Appendix A, Definitions and Explanations). Suchoccurrences are further categorized as to frequency:1

" Incidents of moderate frequency-these areincidents, any one of which may occur during acalendar year for a particular plant.

" Infrequent incidents-these are incidents, anyone of which may occur during the lifetime of aparticular plant.

2.9. Accidents

Accidents are defined as those conditions of abnormaloperation that result in limiting faults: 2

These are occurrences that are not expected to occurbui are postulated because their consequences wouldinclude the potential for the release of significantamounts of radioactive material.

vulnerabilities to the three system failure types described inthe System Failure Guideline (3).

For anticipated operational occurrences as described inGuideline 10 (in combination with primary protectionsystem failure), the goal of defense-in-depth analysis usingbest-estimate (realistic assumptions) methodology is toshow that no more than a small fraction (10%) of the 10CFR 100 dose limit is exceeded, and that the integrity ofthe primary coolant pressure boundary is not violated.

For design basis accidents as described in Guideline 11 (incombination with primary protection system failure), thegoal of defense-in-depth analysis using best-estimatemethodology is to show that any credible failure does notresult in exceeding the 10 CFR 100 dose limits, violation ofthe integrity of the primary coolant pressure boundary, orviolation of the integrity of the containment. The resultinganalysis should be documented as described in Section 5,with details amplified and illustrated similarly to Figures 1-6, Sections 6 through 9, and the Appendix.

3.1. Guideline 1-Choosing Blocks

Since an objective of this analysis method is to view thesubject design at a level of abstraction that reduces the levelof detail, the main criterion for selecting blocks (previouslydefined in Section 2.5) is that the actual mechanism offailure inside a block should not be significant to otherblocks. Therefore, a block is a physical subset of equipmentand software for which it can be credibly assumed thatinternal failures, including the effects of software errors,will not propagate to other equipment or software.Examples of typical blocks are computers, local areanetworks or multiplexers, or PLCs.

Failure propagation modes can be divided into two classes:physical (e.g., electrical) and logical (e.g., by corrupted dataor corrupted interactions caused by software design faults).In general, physical containment of faults is wellunderstood and consists of (but is not limited to) physicalseparation, electrical isolation, electrical shielding, andseparation of power supplies. For instance, it would bereasonable to assume that a computer consisting of printedcircuit cards mounted on an electrically connectedbackplane bus and supplied by a single power supply couldnot be divided into more than one block. Propagation oflogical faults (caused, for example, by software designerrors), however, is not so well understood. In general,logical faults can propagate by the transmission of data 3 forwhich the recipient is unprepared,1 or. by failure to transmitdata for which a recipient is waiting. Almost always,processors on printed circuit cards that are mounted on the

3 More generally, data includes any electrical signal or digitalrepresentation of such a signal.

4 In this context, "unprepared" mcans either not ready in time, asin early or out of sequence, or not able to handle the datum valueor fonnat correctly, as in a program fault caused by inability tohandle corrupted data by taking reasonable default action.

Limiting faults are further defined as those accidents whoseeffects circumscribe or bound the effects of similar faults oflesser magnitude. For the purposes of the analysis describedin this document, a basis set of limiting faults, identical tothose considered in the Standard Safety Analysis Report,Chapter 15, should be identified.

3. ANALYSIS GUIDELINES

Specific guidelines are presented in the sequel forperforming diversity and defense-in-depth analyses. Thisintroductory section describes a road map of how to putthese guidelines together to make a complete analysis.

A block diagram of the system to be analyzed should firstbe constructed using the Block Guideline (1). Candidateblocks should then be examined under the DiversityGuideline (2) to decide which blocks are identical foranalysis purposes, and which will be considered diverse, asrequired by Guideline 7.

With the systemblock diagram and other information assuggested in Section 4, the analysis should be conducted asrequired by the general analysis guidelines (4-14), keepingin mind that the ultimate goal of the analysis is to detect

I Standard Format, Section 15, "Accident Analysis," USNRCReg. Guide 1.70.

2 Ibid.

5 NUREG/CR-6303


same backplane bus are able to interfere with one anotherlogically through shared memory or bus transactions unlesssuch interactions are made physically impossible byhardware design. It is sometimes asserted that two softwaremodules A and B, running in the same computer, areindependent by virtue of protection provided by anoperating system that controls the access privileges of Aand B, or some other non-physical method of separation.This assertion is difficult to defend if it depends upon thereliability of the operating system software that enforces theseparation. Computer systems that are physically separateand electrically isolated may still interfere with one anotherlogically through the medium of local area networkconnections or communication links. The decision aboutwhere to draw block boundaries may hinge upon designcommitments made by the applicant about certainequipment interconnections and logical dependencies.

Criteria for determining physical failure containment are:* Physical separation

* Electrical isolation

* Power supply separation

* Electrical shielding

Criteria for determining containment of logical failures are:* Given two software modules A and B, if it is

physically impossible for a software fault in A to causemodule B to fail, then there is sufficient fault isolationbetween A and B.

* There is no interaction through shared memories.

* There is only unidirectional communication (nohandshaking) with other systems.

The software continues to work regardless of local areanetwork faults (i.e., the software is impervious to errorstransmitted by, or occurring in, networks to which theprocessor running the software is connected).

* All input data from other systems are qualified beforeuse.

5

3.2. Guideline 2-Determining Diversity

During the late 1970s, the following conclusions werereached through work on improving reactor instrumentationsystem reliability (NUREG-0493):

1. Random independent component or subsystem failuresare adequately mitigated by redundancy and should notbe an important part of concerns over control/safetyinterdependence.

5 Format and value arc checked to be sure that subscquentsoftware will not fail if the data are used.

2. Given adequate redundancy, the remaining concern issome sort of non-random, multiple failure or common-mode failure.

3. Physical and electrical independence is the beginning,not the end, of common-mode failure concerns.Related and almost-coincident failures of supposedlyseparate systems can occur because of functionalinteractions, shared signals, common design errors,common environmental effects, and human actions.

For those common-mode effects that can be identified, theusual engineering approach of designing, qualifying,installing, and operating instrumentation systems with greatattention to physical, electrical, and functionalindependence is adequate. However, not all common-modefailures can be predicted, especially those of low-but stillsignificant-probability. For these failures, judicious use ofdiversity is the current state of the art. In the 1979 study ofthe Westinghouse RESAR-414 integrated protectionsystem, the NRC staff took an approach to diversity thestaff termed "approach using a specified degree of systemseparation," by which the staff meant that the (then) threefunctional echelons of defense (control, trip, and ESFAS)were to be sufficiently separated and diverse so thatpostulated CMF events did not lead to unacceptableconsequences. One of the goals of the staff was to avoiddetailed hypotheses and analyses of individual common-mode failures because the number of such analyses requiredwould result in an impossibly large workload. This is still aguiding principle for judging diversity.

Diversity cannot be considered in the absence ofindependence; diverse protection system elements that arenot independent are assumed to fail simultaneously throughinterdependencies. Thus, diversity is not a substitute for,nor should it be proposed instead of the independencerequired by regulation and by standard. Rather, diversityshould be seen as a necessary accessory to independencefor increasing system robustness in the face of unidentifiedcommon-mode failures.

For purposes of this guideline and convenience inassessment, diversity will be assumed to be separable intosix attributes, listed in alphabetical order:

* Design diversity

* Equipment diversity

Functional diversity

* Human diversity

• Signal diversity

* Software diversity

To determine the degree of diversity between two blocks,subsystems, or items of equipment, each block, subsystem,or item should be assessed with respect to the diversity

NUREG/CR-6303


attributes. A set of recommended criteria is listed below foreach attribute. A documented basis for claimed diversityattributes should be assembled, with arguments orsupporting data.

After assessing individual diversity attributes between twoblocks, subsystems, or items of equipment, the combinedassessment should be used to present an argument that theone is either diverse or not diverse from the other.Following the suggested criteria for judging diversityattributes, an example is given for computer-based systemsof combining such results to reach a diversity conclusion.

3.2.1. Design Diversity

Factors increasing diversity between two designs meetingthe same requirements--excluding the effects cf humandiversity-are listed here in decreasing order of effect:

* Different technologies (e.g., analog versus digital)

* Different approaches within a technology (e.g.,transformer-coupled AC instrumentation versus DC-coupled instrumentation)

* Different architecture (i.e., arrangement andconnection of components)

3.2.2. Equipment Diversity

Factors increasing equipment diversity between two groupsor items of equipment are listed here in decreasing order ofeffect:

* Different manufacturers of fundamentally differentdesigns

* Same manufacturer of fundamentally different designs

* Different manufacturers making the same design

* Different versions of the same design

In computer equipment, there are additional details whichhelp in judging the degree of diversity:

* Different CPU architecture (e.g., Intel 80X86architecture versus Motorola 68000)

* Different CPU chip versions (e.g., Intel 80386 versusIntel 80486)

* Different printed circuit board designs 6

* Different bus structure (e.g., VME versus Multibus I1)

6 Besides the processor board (or boards), a computer willprobably contain memory boards, peripheral control boards, andspecial-purpose boards designed by the applicant or other customdesign house.

It is worth mentioning that different CPU architecture is avery powerful sort of diversity, since this forces differentcompilers, linkers, and other auxiliary programs to be used.This also illustrates the deep connection between somediversity attributes; §ix attributes are presented forconvenience of assessment, but this does not mean that theyare independent of each other.

3.2.3. Functional Diversity

Factors increasing functional diversity between twoindependent subsystems are listed here in decreasing orderof effect:

Different underlying mechanism (e.g., gravityconvection versus pumped flow, rod insertion versusboron poisoning).

Different purpose, function (e.g., normal rod controlversus reactor trip rod insertion), control logic, oractuation means.

* Different response time scale (e.g., a secondary systemmay react if accident conditions persist for a time).

3.2.4. Human Diversity

Factors increasing the human diversity of a design indecreasing order of effect are:

* Different design organization (i.e., company).

Different engineering management team within thesame company.

Different designers, engineers, or programmers. 7

* Different testers, installers, or certification personnel.

Management has the most significant effect on diversitybecause management controls the resources applied and thecorporate culture under which designers, engineers, orprogrammers work. Poor resource allocation and a lack of"quality" commitment can vitiate the effectiveness of usingdifferent personnel. The relative importance of the humandiversity attribute is the most difficult to assess of all thediversity attributes. It should be noted in this regard thatdiversity and quality are different issues; using a separateorganization that has little experience with nuclear powerplant protection systems may guarantee diversity, but it alsomay guarantee many fundamental errors that a moreexperienced, but possibly less diverse, organization wouldavoid.

3.2.5. Signal Diversity

Factors increasing signal diversity between two signalsources are listed here in decreasing order of effect:

7 Designers, engineers, or programmers are sometimes shared bydifferent management teams.

7 NUREG/CR-6303


* Different reactor or process parameters sensed bydifferent physical effects (e.g., pressure or neutronflux).

* Different reactor or process parameters sensed by thesame physical effect (e.g., pressure versus water levelor flow sensed by differential pressure sensors).

The same reactor or process parameter sensed by adifferent redundant set of similar sensors (e.g., a set offour redundant water level sensors backed up by anadditional set of four redundant water level sensorsdriving a diverse design of protective equipment).

3.2.6. Software Diversity

Factors increasing diversity between software designsmeeting the same requirements, excluding the effects ofhuman diversity, are listed here in decreasing order ofeffect:

* Different algorithms, logic, and program architecture

* Different timing, order of execution

* Different operating system

* Different computer language

Another way of expressing these points is that softwaremust differ significantly in parameters, dynamics, and logicto be considered diverse, but only if the "operating system"is sufficiently simple that it can be considered a small set ofdemand-driven subroutines. More complex operatingsystems introduce significant difficulties in analysis andmay limit the independence that can be achieved, regardlessof the quality of the safety software that uses the operatingsystem. In other words, two different safety-criticalsubsystems that use the same operating system may besubject to CMF through the operating system even if noCMF exists in the safety software. The reason thatcomputer language, for example C, Ada, or Pascal. is notlisted among the more effective criteria, is that modernlanguages are converging, offer a common set of features,and can often be intermixed at the subroutine level.Computer language, therefore, has little effect onalgorithms, logic, architecture, timing, or operating systemservices.

3.2.7. Combining Diversity Attributes

Once an assessment of diversity attributes is made, theresults can be combined to make an overall decision or todeclare, for instance, that sufficient signal diversity exists.Which diversity attributes assume the greatest importancedepends upon the situation. Since this document concernsdiversity and defense-in-depth of computer-based reactorprotection systems (including ESFAS), the immediatediscussion will be limited to determining diversity ofvarious architectures in that context.

For example, the clearest distinction between two candidatesubsystems would be design diversity; a non-digitalsubsystem would easily be considered a diverse alternativeto a digital subsystem. Between two digital systems(limited design diversity), different computer equipment(equipment diversity) made by different manufacturers(human diversity) would be considered diverse providedthere was some functional and signal diversity or somesoftware diversity. Some caution is indicated even wherethere is apparent computer equipment diversity, sinceprogram portability is now fairly common and the samesoftware may run on two different computer types. In thelikely instance of the same developer (limited humandiversity) and similar equipment (limited equipmentdiversity), then software diversity coupled with eitherfunctional diversity or signal diversity would probably benecessary to declare that two subsystems were diverse.

In any case, the basis for claiming that a particularcombination of diversity attributes constitutes sufficientdiversity should be documented.

3.3. Guideline 3-System Failure Types

Guidelines 5 and 6 describe the method for postulatingcommon-mode failures of blocks of the protective system.The system-level effects of these postulated CMFs aredescribed here as three intsrumentation system failuretypes, in order to clarify what the analyst should look for.Note that these failures are not the same as those consideredin SAR Chapter 15 analyses.

3.3.1. Type I Failures

Failures of type I happen when a plant transient is inducedby the instrumentation system for which reactor trip or ESFfunction is needed, but may not occur, because of aninteraction between echelons of defense. Type 1 failurestypically begin with a challenge presented by the controlsystem to the reactor trip system or to the ESFAS due tofailure of a common sensor or signal source. Defenseagainst such failures depends upon means of accomplishingsafety functions that are diverse to the shared signals orequipment (i.e. not impaired by the postulated common-mode failure). Defense-in-depth analysis of type 1 failuresis required by general analysis Guideline 12.

3.3.2. Type 2 Failures

Failures of type 2 do not directly cause plant transients butare undetected until environmental effects or physicalequipment failure cause a plant transient or design basisaccident to which protective equipment may not respond.Failure to respond is due to postulated common-modefailure of redundant protection system divisions or portionsthereof. Type 2 failures can have serious consequences onlyif the event needing safety action occurs while theprotection system is in the failed state and before the failure.is repaired. Defense against type 2 failures depends uponsome combination of diverse control system, reactor tripsystem, ATWS mitigation equipment, ESFAS, and

NUREGICR-63038 8

monitoring and indication functions that are sufficient tomitigate the postulated incident. Defense-in-depth analysisof type 2 failures is required by general analysis Guidelines10and 11.

3.3.3. Type 3 Failures

Type 3 failures occur because, for some reason the primarysensors expected to respond to a design-basis event insteadproduce anomalous readings. For instance, accidentconditions may have modified instrument response or anunanticipated event sequence may have modified theparameter values seen by the instrumentation (Hanauer andWalker 1968). Since type 3 failures are unpredictable bydefinition, a strategy dictated by experience is to ensuresufficient signal diversity that alternate means of detectingsignificant events exist. At a minimum, there should besufficient signal diversity to ensure that for each anticipatedoperational occurrence in the design basis in conjunctionwith postulated CMFs, the plant shall be brought to a stablehot standby condition. For each accident in the designbasis in conjunction with postulated CMFs, the plantresponse calculated using best-estimate (using realisticassumptions) analyses should not result in exceedance ofthe 10 CFR 100 dose limits, violation of the integrity of theprimary coolant pressure boundary, or violation of theintegrity of the containment. Defense-in-depth analysis thatsupports signal diversity required for type 3 failures isrequired by general analysis Guidelines 10 and 11.

3.4. Guideline 4-Echelon Requirement

The instrumentation system should provide four echelonsof defense-in-depth: control, reactor trip, engineered safetyfeatures (ESF) actuation, and monitoring and indicatorsystem.

The control echelon is that non-safety equipment whichroutinely prevents reactor excursions toward unsaferegimes of operation and is used for normal operation of thereactor.

The reactor trip echelon is that safety equipment designedto reduce reactivity rapidly in response to an uncontrolledexcursion.

The ESFAS echelon is that safety equipment that removesheat or otherwise assists in maintaining the integrity of thethree physical barriers to radioactive release (cladding,vessel, and containment).

The monitoring and indication echelon is that set ofsensors, safety parameter displays, and independent manualcontrols required for intelligent human response to events.

In other words, echelons are defined by their function,while the instrumentation that initiates those functionsresides in what are nominally called the control system, thescram or reactor trip system, the engineered safety featuresactuation system (ESFAS), the safety parameter displaysystem, or the manual controls.


The monitoring and instrumentation echelon allowsoperators to compensate for control system excursions, or,in some cases, for failure of one of the two automatic safetyechelons. The usual definition of Class IE equipment(equipment essential to safety) still applies.

In general, the normal operational hierarchy for transientsand accidents is that the second echelon (reactor trip)functions when the first (control) fails, and the third(ESFAS) and fourth (monitoring and indication) echelonssupport the first two. In the analysis method presented inthis document, this order is sometimes reversed when non-Class IE echelons are allowed to compensate for rarecommon-mode failures in Class IE echelons (see Section1.1, requirement 3).

3.5. Guideline 5-Method of Evaluation

The protection system is usually subdivided into redundantdivisions, with each division consisting of interconnectedblocks as described in Sections 2.1, 3.1, and 9.2. Eachblock should be considered a "black box," so that anyfailure required to be postulated within the block fails alloutput signals. Block output signals must be assumed to failin a manner that is credible but that produces the mostdetrimental consequences when analyzed in accordancewith Guideline 9. In blocks containing software, it iscredible that outputs shall assume values irrespective ofinputs because the only logic connecting inputs to outputsis software, and the effects of software failures on outputsare unpredictable.

3.6. Guideline 6-Postulated Common-ModeFailure of Blocks

Analysis of defense-in-depth should be performed bypostulating concurrent failures of the same block oridentical blocks (as defined in Guideline 7) in all redundantdivisions. Since several channels may pass through thesame block or identical blocks, such common-mode failureshave the potential to cause multiple channel failures in asingle division, with the same failure replicated across all(four) protection system divisions. The output signals of theblocks thus postulated to fail should do so in accordancewith Guideline 5. In other words, signals entering failedblocks assume the most adverse credible values on output,essentially losing their protective function at that point.Subject to Guidelines 7, 8, and 9, concurrent failure of eachset of identical blocks in all divisions should be postulatedin turn (until the list of diverse blocks has been exhausted),and the result of the failure should be documented as afinding of the analysis.

3.7. Guideline 7-Use of Identical Hardwareand Software Modules

Blocks are to be considered identical for the purposes of thepostulated common-mode failures required in Guideline 6when the likelihood of a CMF affecting themsimultaneously is not acceptably low. This means that the

9 NUREG/CR-6303


probabilities of block failure are not independent and theprobability of system failure cannot be calculated by simplymultiplying block failure probabilities. Guideline 2 shouldbe used to provide the basis for judging diversity of blocks.

3.8. Guideline 8-Effect of Other Blocks

During any postulated common-mode failure, signals fromfailed blocks are propagated to downstream blocks, whichreact to the possibly erroneous signals. Subject toGuidelines 7 and 9, the other blocks are assumed tofunction correctly in exact response to all correct orincorrect inputs they receive.

3.9. Guideline 9-Output Signals

Output signals are assumed to function one-way; that is,failures cannot propagate backwards into an output of aprevious block. In cases where a block has more than oneoutput signal, no output signal should be significantlyinfluenced by any credible change or failure of equipmentto which any other output signal is connected. Thisguideline includes any signal transmission paths involvingmultiported memory, local area networks, serialcommunication links, or multiplexers. If compliance withthis guideline cannot be demonstrated, block definitions areincorrect and involved blocks should be redefined so thatblocks mutually affected through output interconnectionsare coalesced into one block.

3.10. Guideline 10-Diversity for AnticipatedOperational Occurrences

For each anticipated operational occurrence in the designbasis 8 which occurs in conjunction with each postulatedCMF, the calculated plant response should not exceed asmall fraction (10%) of the 10 CFR 100 dose limit orviolate the integrity of the primary coolant pressureboundary. This guideline covers instrumentation systemCMFs of types 2 and 3 (Guideline 3) for anticpatedoperational occurrences. A part of the analysis describedherein should either (1) demonstrate that sufficient diversityexists to achieve these goals, or (2) identify thevulnerabilities discovered and the corrective actions taken,or (3) identify the vulnerabilities discovered and provide adocumented basis that justifies actions not taken.

3.11. Guideline 1 ]-Diversity for Accidents

For each limiting fault in the design basis 9 which occurs inconjunction with each postulated CMF, the combinedaction of all echelons of defense should ensure thatequipment provided by the design and required to mitigatethe effects of the accident is promptly initiated, supportedby necessary auxiliary equipment, and operated for thenecessary period of time. This guideline covers

instrumentation system CMFs of types 2 and 3 (Guideline3) for accidents. The plant response calculated using best-estimate (using realistic assumptions) analyses should notexceed the 10 CFR 100 dose limits, violate the integrity ofthe primary coolant pressure boundary, or violate theintegrity of the containment. A part of the analysisdescribed herein should either (1) demonstrate thatsufficient diversity exists to achieve these goals, or (2)identify the vulnerabilities discovered and the correctiveactions taken, or (3) identify the vulnerabilities discoveredand provide a documented basis that justifies actions nottaken.

3.12. Guideline 12-Diversity AmongEchelons of Defense

The control system, which includes most instrumentationand control equipment not part of the protection system, isnot required to be Class IE. The plant design basis includespostulated failures, some involving the control system, forwhich the reactor trip and the ESF actuation systems mustprovide ample protection. Yet the control system, eventhough not Class IE equipment, plays three important rolesin defense-in-depth. First, most disturbances are controlledwithout the need for action by the protection system.Second, failures in the control system may challenge theprotection system. Third, during an incident in which oneof the protection system echelons (reactor trip or ESFAS) isincapacitated by a CMF, the control system may mitigatethe disturbance. From the first two roles, it is evident thatthe control system largely determines the frequency ofchallenges to the protection system, which by fault-tolerantdesign is expected to function reliably in response. Only inthe third role is the control system actively involved as adiverse echelon of defense, in the rare instance that theprotection system fails to function due to CMF. To preventthe protection system from failing in the second role and topreserve the control system's ability to act in the third role,it is important that transients or control system failures(type I failures described by Guideline 3) needingprotection system action should not also induce protectionsystem failures, or, in short, that the control system and theprotection system should not be disabled by the same singlefailure. This concern is stated by GDC 24 of 10 CFR 50Appendix A (separation of protection and control systems),the IEEE 279 requirement for no interaction betweenprotection and control due to single random failures, andalso by the IEEE 379 inclusion of identifiable cascadedfailures within the definition of single failures.

Diversity between echelons is therefore necessary and is aconcern of this analysis. The instrumentation and controlsystem should be exaimined for potential interactionsbetween the four echelons of defense, the control system,the reactor trip system, the ESFAS, and the monitoring andindicator system, with the intention of determining that thefunctions of at least two out of the four echelons of defense

8 Usually these are elucidated in Section 15, "Accident Analysis,"USNRC Reg. Guide 1.70.

9 Ibid.

NUREG/CR-6303 10

are unimpaired by interconnections. 10 'In some cases, semi-independent subsystems such as ATWS mitigationequipment, may initiate functions of several echelons. Insuch cases, any additional interactions that maysimultaneously disable one or more echelons of defense andmay also disable the diverse semi-independent subsystemshould be investigated. For example, when elements areshared between ATWS mitigation equipment and either thereactor trip system or the ESFAS, the analyst should ensurethat the same failure that incapacitates the primary echelonof defense does not also disable the ATWS mitigationequipment, or that the consequences are acceptable. In thefollowing, potential interactions between the nominalechelons are considered.

ControllReactor Trip Interaction

When a CMF of a common element or signal source sharedbetween the control system and, the reactor trip system ispostulated according to Guidelines 5 through 9, and (1) thisCMF results in a plant response that requires reactor tripand (2) the CMF also impairs the trip function, then diversemeans, which are not subject to or failed by the postulatedCMF, should be provided to ensure that the plant responsecalculated using best-estimate (using realistic assumptions)analyses should not exceed a small fraction (10%) of the 10CFR 100 dose limit or violate the integrity of the primarycoolant pressure boundary. The diverse means may includemanual action if the conditions of Guideline 14 are met.

Control/ESFAS Interaction

When a CMF of a common clement or signal source sharedbetween the control system and the ESFAS is postulatedaccording to Guidelines 5 through 9, and (1) this CMFresults in a plant response that requires ESF and (2) theCMF also impairs the ESF function, then diverse means,which are not subject to or failed by the postulated CMF,should be provided to effect the ESF function and to ensurethat the plant response calculated using best-estimate (usingrealistic assumptions) analyses should not exceed a smallfraction (10%) of the 10 CFR 100 dose limit or violate theintegrity of the primary coolant pressure boundary. Thediverse means may include manual action if the conditionsof Guideline 14 arc met.

Reactor Trip/ESFAS Interaction

Interconnections between reactor trip and ESFAS (forinterlocks providing for (1) reactor trip if certain ESFs areinitiated, (2) ESF initiation when a reactor trip occurs, or(3) operating bypass functions) are permitted provided itcan be demonstrated that functions required by the ATWSrule (10 CFR 50.62) are not impaired under the constraintsof Guidelines 8 and 9.


3.13.. Guideline 13-Plant Monitoring

Signals may be transmitted from the reactor trip and theESFAS to the control system or other display systems forplant monitoring purposes provided that all guidelines aremet (with special attention to Guidelines 8 and 9) and theindependence required by regulations and standards ismaintained (GDC 24-10 CFR 50 Appendix A, IEEE 279,IEEE 603, IEEE 379, and IEEE 384). In addition, theCommission has approved the following requirements foralarm systems in ALWRs:

[...] alarm systems for ALWRs should meet theapplicable EPRI requirements for redundancy,independence, and separation. In addition, alarms thatare provided for manually controlled actions for whichno automatic control is provided and that are requiredfor the safety systems to accomplish their safetyfunctions, shall meet the applicable requirements forClass IE equipment and circuits (SECY-93-087 asapproved). For example, type A variables in RegulatoryGuide 1.97, Revision 3.

Connections and software used for plant monitoring and forsurveillance of the reactor trip and ESF actuation systemsshould not significantly reduce the reliability of or increasethe complexity of these systems. No failure of monitoringor display systems should influence the functioning of thereactor trip system or the ESFAS. A part of the analysisdescribed herein should address the possibility that failureof the plant monitoring system may induce operators toattempt to operate the plant outside safety limits or inviolation of the limiting conditions of operation. Theanalysis should demonstrate that such operator-inducedtransients will be compensated by protection systemfunction, or a basis should be documented for claiming thatthe identified operator-induced transients are either notcredible or result in no damage.

3.14. Guideline 14-Manual Operator Action

The fourth point of the Commission's diversity position(Section 1.1, item 4) requires that independent and diversedisplays and manual controls be available so that operatorscan initiate a system-level actuation of critical safetyfunctions. To verify this, the analysis should identify thecritical safety functions, identify variables necessary foroperator decisions using Regulatory Guide 1.97 forguidance, and demonstrate that the required sensorchannels, displays, and manual controls are diverse andindependent from the other three echelons (control, reactortrip, and ESFAS). In addition, manual operator action ispermissible as a diverse means of response to postulatedCMFs if the following criteria are met:

10 Credit can be taken for operator action under restrictedcircumstances. See Guideline 14 inSection 3.14.

I1I NUREG/CR-6303

Section 4. Data Required

* The postulated CMF and its effects do not impair anyrelated aspect of the manual action, includinginformation displayed that is necessary for operatoraction.

* Sufficient information is available to the operator.

* Sufficient time is available for operator Ana lysis,decision, and action.

*Su fficient informnation and time is available for theoperator to detect, analyze, and correct reasonablyprobable errors of operator function.

4. DATA REQUIRED TO DO THEANALYSIS

Besides the general guidelines and other backgroundinformation, a diversity and defense- in-depth analysisrequires certain specific information, some of which isunique to this analysis process. This section describes themain analysis data inputs.

4.1. System Diagram and Logic Diagrams

A system diagram showing one division (of multipleredundant divisions) of the protective system to be analyzedis required. Additional detailed logic diagrams or textualdescriptions may be necessary so that system response tovarious events can be determined by the analyst. Thesystem diagram is equivalent to a single-line electricaldiagram in that it is an abstraction that presents the systemarchitecture at a level of detail appropriate to "block"failure analysis. Two examples are shown in the Appendix.A number of applicant design drawings and textdescriptions often must be consolidated and re-drawn onone drawing as an arrangement of interconnected blocks,where the blocks are those chosen as described in Sections2.5 and 3.1 of this document.

4.2. Chapter 15 Events

In most instances, the SAR Chapter 15 events form thebasis set of anticipated operational occurrences andaccidents which will be used to challenge the protectivesystem design. The applicant usually presents simulationcurves of reactor parameters during the Chapter 15incidents which at least determine the primary tripvariables, but often exclude secondary trips due topostulated prompt protection system action. This isappropriate, considering the goals of Chapter 15 analyses.Chapter 15 analyses are also performed under conservative,rather than best-estimate, assumptions.

4.3. Alternate Trips

Because the purpose of diversity and defense- in-depthanalysis is to determine whether sufficient diversity ordefense- in-depth exists to compensate for primary trip (or

ESF initiation) failure, it is necessary to know whichsecondary trip or initiation signals will activate defenses, ifany, if primary signals or signal paths. fail. Sometimes thisis possible if trip point values are known and simulationcurves of an incident or a closely similar incident show thatalternative reactor parameters exceed trip values. Whensuch informnation exists, a secondary trip will occur underconservative assumptions, although it is sometimes notclear whether, for less severe event sequences, a secondarytrip point will be reached. In cases in which secondary tripscannot be clearly, determined, it may be necessary toperform simulations that assume the primary trip variablefails. A set of best-estimate (using realistic assumptions)secondary trip sequences for events lacking a clearsecondary trip should be deduced or obtained. Analternative to secondary trip data is best-estimate analysesthat demonstrate for each such event that all possiblesequences lead to safe conclusions.

4.4. Required Mitigation

Success or failure of protective system action, whether byprimary or alternate trip variables, is determined solely bythe actuation of, or failure to actuate, appropriate mitigationmeasures. For this, the analyst needs to know the mitigationmeasures required for satisfactory response to the designbasis incidents. For example, uncomplicated generator load.rejection, an incident of moderate frequency, usuallyrequires no more than reactor trip (if that), and normalcondenser cooling operation is sufficient to protect fuelcladding. On the other hand, emergency cooling is requiredfor a large loss of coolant accident inside containment.

5. WHAT SHOULD BE IN ANANALYSIS?

The report of a diversity and defense- in-depth analysisshould explain why and how the analysis was done insufficient detail that a competent reviewer can identify theunderlying bases and assumptions and follow the reasoningto the report's conclusions. Normally an analysis will bepresented as a report body, which describes significantfeatures and results, to which is attached one or moreappendices which contain the detailed work. The followingsuggested format, presented in brief outline in this section,is a structure that accomplishes these purposes.

NUREG/CR-6303 112

Section 5. Analysis Contents

1. Introduction

An introduction identifies the design being evaluatedand those doing the evaluation.

2. Purpose

Purpose describes the certification or approval for whichthe evaluation is being performed, or other reasons, ifapplicable.

3. Background

Background cites relevant regulatory or applicanthistory and places this particular analysis in historicalcontext.

4. New or Unusual Design Features

New or unusual features of the analyzed design whichmay affect the analysis process or outcomes should benoted.

5. Scope

The scope of the current analysis is important to bothanalyst and reviewer to ensure appropriate coverage.What is not in the scope is just as important as what is inthe scope.

5.1. What is in Scope

The subsystems and equipment being analyzed shouldbe identified. The types of failure being postulatedshould be stated. The basis set of anticipated operationaloccurrences and accidents to be used should be stated orreferenced.

5.2. What is not in Scope

Subsystems and equipment being excluded should beidentified and reasons for the exclusion should be stated.Certain failures that are incredible or do not fit thedefinition of common-mode failure as used in theanalysis should be described and reasons given for theirexclusion.

6. Description of Analysis Methods

The analysis methods and their derivation from variousauthorities and guidelines should be described in detail.It is particularly important to discuss deviations fromstandard methods or assumptions made to clarifymissing, incomplete, or inconsistent information

provided by design descriptions (which usually

accompany a Standard Safety Analysis Report).

7. Authorities and Guidelines

Guidelines for performing the diversity and defense-in-depth analysis are given in Section 3, and should bereferred to in this section of the analysis document.However, these guidelines do not supplant or supersedethe general design criteria of 10 CFR 50, Appendix A,or other standards or design bases required by regulationor practice. Such criteria or standards as are applicableto the design should also be stated here. Criteria andstandards are covered at greater length in Section 7.1 ofthis document.

8. Types of Failures

The types of failures to be considered in the analysisshould be noted here. See Section 3.3 of this documentfor further detail.

9. Sources of Design Information

The sources from which design information was takenshould be cited.

10. Assumptions

Rarely is a design so perfect that there are nouncertainties in its description. Practically, there will beuncertainties of material effect, and these should bedescribed and resolved by stated assumptions that canbe reviewed and corrected later, if necessary, by others.In the three analyses performed by independentcontractors in 1992 and 1993, the assumptions sectionhas proved to be a significant section. Assumptions aremore fully covered in Section 6 of this document.

11. D)escription of the Design

Even if a diversity and defense-in-depth analysis isbeing performed by an applicant rather than anindependent contractor, constructing an accurate designdescription may be an educational experience. Thissection, the assumptions section (described above), anda system diagram (Section 4.1 of this document)combine to provide an accurate description of the designto be. analyzed. This section should be a high-level textdescription that, combined with the system diagram,lays out the system architecture and the details of the

13 NUREG/CR-6303

Section 6. Assumptions

design that are material to the analysis. Design

description is elaborated in Section 7 of this document.

12. Findings

This section contains the analysis findings organized asdescribed previously. Certain graphical aids topresenting results are suggested in Section 9 of thisdocument.

13. References

Standards, regulations, and publications (such as thisone) used during the preparation of the analysis shouldbe cited in this section.

14. Appendices

The appendices contain the actual analysis worksheetsand narratives. Section 9 describes an analysisworksheet that may be useful for systematicdocumentation of analysis details..

Autodiagnostic Software

Autodiagnostic software is assumed to detect onlymalfunctions anticipated by software designers, butnot unintended errors made by software designers.

Latency of Failures

Failures are assumed to be latent and undetectableuntil stressed by event or accident, at which time thefailure becomes manifest.

6.2. Assumptions Based on System Structure

System structure is the crux of defense-in-depth anddiversity analysis. The assumptions in this section shoulddescribe what portions of the design have potential forcommon-mode failures and how and why blockdelineations were made. The example below, from a BWRanalysis, describes the assumptions made regarding theblocks at risk of CMF:

6. ASSUMPTIONS TO BE STATED

The assumptions made by the analyst arc crucial tounderstanding the decisions made during analysis. Thissection provides examples of subjects that should becovered, although there will be differences in detaildepending upon the design being analyzed. Statement ofthe analysis assumptions is important because it permitseasier and faster resolution of misunderstandings, shouldthey arise.

6.1. Worst-Case Assumptions

The worst-case assumptions describe the particularapplication of Guideline 5 to the subject design. In thefollowing example, the handling of an applicant's stateddesign features is described. In this instance the featuresdiscussed are "energize to trip," "de-energize to trip,''"deadman timers," and "autodiagnostic software." Theassumption on failure latency is the worst-case assumptionapplied to surveillance effectiveness.

BWR CMF Blocks

The RPS consists of the assembly shown in theSystem Diagram. Of the objects shown in thatdiagram, only Digital Trip Modules (DTMs), TripLogic Units (TLUs), and the Essential MultiplexorSystem (EMS) contain software.

CMF blocks in a PWR were:

PWR CMF Blocks

The IEEE-796 standard bus is used as theinterconnect between the logic cards which make upthe various subsystems of the protection system.Communication between subsystems is carried on byother means. Therefore the blocks used in thisanalysis consist of the subsystems, where eachsubsystem uses a single IEEE-796 bus forinterconnection of the logic cards of the subsystem.NUREG-0493 'Measured Variable Blocks' and'Derived Variable Blocks' cannot usefully beidentified in this design.

Failure Consequences

Failures are assumed to occur in the most limitingfashion possible consistent with hardware orsoftware construction. For example, a module whichenergizes to trip is assumed to take no action, or amodule which de-energizes to trip is assumed to failso that it continues to block trip. Deadman timers areassumed to continue to be reset as if the subsystemwere functioning normally.

NUREG/CR-6303 14

Section 6. Assumptions

This choice is made because a subsystem so definedappears to be the smallest block into which the(reactor) protection system can be subdivided withcredible restrictions on block-to-block faultpropagation. Hardware or software failure of anyprinted circuit board in an IEEE-796 chassis isassumed to fail the entire chassis. It is assumed thatsome failures are not detected by the watchdogtimer.

6.2.1. Diversity of Blocks

Guideline 7 requires that "identical" blocks in a design bedetermined. Guideline 2 provides criteria for determiningdiversity (or similarity) among subsystems, and this sectionshould describe the precise application of Guideline 2 to theinstant design so that it is clear which blocks are consideredidentical. Here, the application of Guidelines 2 and 7 isstated for a BWR design, followed by substantially thesame example for a PWR:

enough that surveillance is insufficient to detect thefailures in time for effective repair. (This assumptionimplies common-mode failures in DTMs of similarinputs, TLUs of similar inputs, and the EMS.)

Guideline 2 Applied to a PWR

The standard for independence between twosubsystems as defined (in Guideline 2) is that theymust differ significantly in parameters, dynamics,and logic. If two such subsystems perform similarfunctions but have differing inputs (differentparameters being sensed) combined by differentlogic, it is assumed that the two subsystems do nothave a common failure mode. This assumption isreasonable since it is implicit that the programsbeing run will differ in timing and logic because ofthe differing inputs and processing code.

In contrast, IEEE-796 subsystems with the samefunctions, hardware, and similar inputs (as exist infunctionally identical subsystems in separateprotection system divisions) are assumed to havecommon failure modes due to potential replicatedsoftware errors. These subsystems are substantiallythe same in parameters, dynamics, and logic. Suchfailures need not occur at identical times, but merelyclose enough that surveillance is evaded. (Thisassumption implies common-mode failures in the RTgroups, ESF groups, Engineered Safety FeaturesActuation Subsystems (ESFAS), PLCs, Trip Enable,or Global Trip subsystems of each division; failureof the ESFAS would disable automatic initiation ofESF equipment, while still allowing manualinitiations; a PLC failure would disable automaticand manual initiation of all ESF equipment; failureof the Trip Enable Subsystem would incapacitateautomatic partial reactor trips from the Reactor TripSubsystems, but Global Trips and manual tripswould still be available; a common mode failure ofthe Global Trip subsystems prevents any automaticreactor trip, while still allowing manual trip.)

Guideline 2 Applied to a BWR

The standard for independence between twosubsystems as defined above is that they must differsignificantly in parameters, dynamics, and logic. Iftwo such subsystems perform similar functions buthave differing inputs (different parameters beingsensed) combined by different logic, it is assumedthat the two subsystems do not have a commonfailure mode. This assumption is reasonable since itis implicit that the programs being run will differ intiming and logic because of the differing inputs andprocessing code. By this standard, DTMs withdiffering inputs will differ from each other, andTLUs with differing inputs will be independent ofeach other.

In contrast, subsystems with the same functions,hardware, and similar inputs (as exist in functionallyidentical subsystems in separate protection systemdivisions) are assumed to have common failuremodes due to potential replicated software errors.These subsystems are substantially the same inparameters, dynamics, and logic. Such failures neednot occur at identical times, but merely close

6.3. Assumptions for EchelonDefense-in -Depth

The equivalent of the four nominal echelons, control, trip,ESFAS, and monitoring and indicator must be identified ina design. Defense-in-depth assumptions describe thearrangement of echelons of defense

15 NUREG/CR-6303

Section 7. DesigQn Description

(which equipment is part of which echelon), necessarymitigations or effectiveness of certain mitigationequipment, and any other assumptions necessary to clarifywhich combinations of equipment must function during theevents studied. In some instances, this may requireidentifying and categorizing equipment such as thatdesigned to satisfy the ATWS rule, but which crossesnominal echelon boundaries in its effects.

6.4. Evaluation Criteria

The criteria for success are stated in Guidelines 10 through12 for event responses and in Guideline 13 for plantmonitoring. Any deviation or additional criteria should bestated here. By default, the applicant's list (if such a listexists) of necessary and sufficient mitigation actions forvarious events is considered sufficient protection systemresponse to fulfill Guidelines 10 through 12. These actions,or the list reference, would normally be detailed in theprevious section on echelons of defense.

7. DESCRIPTION OF THE DESIGN

The design being analyzed should be described withemphasis on factors that are important to diversity anddefense in depth. This is not merely a repetition of theapplicant's SAR submission, which may be detailed, but isa critical selection from what may be voluminous materialof that part that forms the basis for analytic decisionmaking. A design description consists of three parts: thedesign basis which any successful design must satisfy, adescription of the design architecture (probably supportedby a number of drawings), and a description of intentionaldiversity in the design.

7.1. Design Basis

Design bases are the rules under which a design is executedand they specify general qualities that the resulting designwill satisfy. In cases where it may not be clear from detailshow to decide a particular analytic question, the designbasis may provide guidance sufficient to make the decision.Certain design qualities are mandated by regulation andthese are listed below under "General or RegulatoryBases." An applicant may also have agreed or may havevolunteered to use certain standards or techniques.

7.1.1. General or Regulatory Bases

Design basis requirements pertinent to defense- in-depth anddiversity for the light water reactor designs include theregulations and standards summarized in this section.

10 CFR 50 Appendix A, "General Design Criteria" statesin part in the introduction that:

The development of these General Design Criteria isnot yet complete... (S)ome of the specific designrequirements for structures, systems, andcomponents important to safety have not as yet beensuitably defined. Their omission does not relieve anyapplicant from considering these matters in thedesign of a specific facility and satisfying thenecessary safety requirements. These mattersinclude:

..(2) Consideration of redundancy and diversityrequirements for fluid systems important to safety...(T)he minimum acceptable redundancy and diversityof subsystems and components within a subsystem,and the required interconnection and independenceof the subsystems have not yet been developed ordefined. (See Criteria 34, 35, 38, 41, and 44).

(4) Consideration of the possibility of systematic,nonrandom, concurrent failures of redundantelements in the design of protection systems andreactivity control systems. (See Criteria 22, 24, 26,and 29).

..There will be some water-cooled nuclear powerplants for which the General Design Criteria are notsufficient and for which additional criteria must beidentified and satisfied in the interest of publicsafety. In particular, it is expected that additional ordifferent criteria will be needed... for water-coolednuclear power units of advanced design.

From the General Design Criteria of 10 CFR 50Appendix A:

21. Protection system reliability and testabilityrequires in part that .".... no single failure results inloss of the protection system..."

22. Protection system independence requires inpart that, "design techniques, such as functionaldiversity or diversity in component design andprinciples of operation, shall be used to the extentpractical to prevent loss of the protection function."

NUREG/CR-6303 116

Section 7. Design Description

23. Protection system failure modes requires that,"the protection system shall be designed to fail in asafe state or into a state demonstrated to beacceptable on some other defined basis if conditionssuch as disconnection of the system, loss of energy(e.g., electric power, instrument air) or postulatedadverse environments (e.g., extreme heat or cold,fire, pressure, steam, water, and radiation) areexperienced."

24. Separation of protection and control systemsrequires in part that, "interconnection of theprotection and control systems shall be limited so asto assure that safety is not significantly impaired."

29. Protection against anticipated operationaloccurrences requires that, "the protection andreactivity control systems shall be designed to assurean extremely high probability of accomplishing theirsafety functions in the event of anticipatedoperational occurrences."

protection channels. Both the principal and alternateprotection channels shall meet all the requirements.of this document.

4.7.4.2, Equipment, not subject to failure caused bythe same credible single event, shall be provided todetect the event and limit the consequences to avalue specified by the design bases. Such equipmentshall meet all the requirements of this document.

10 CFR 50.55a(h) requires that protection systems meet therequirements of IEEE Sid 279. IEEE Std 279 includes thefollowing requirements:

4.17, Manual Initiation. The protection system shallinclude means for manual initiation.

4.2, Single Failure Criterion. Any single failurewithin the protection system shall not prevent properprotective action at the system level when required.

4.6, Channel Independence. Channels that providesignals for the same protective functions shall beindependent and physically separated.

4.7.4, Multiple Failures Resulting From a CredibleSingle Event. Where a credible single event cancause a control system action that results in acondition requiring protective action and canconcurrently prevent the protective action from thoseprotection system channels designated to provideprincipal protection against the condition, one of thefollowing must be met.

4.7.4.1, Alternate channels, not subject to failureresulting from the same single event, shall beprovided to limit the consequences of this event to avalue specified by the design bases. In the selectionof alternate channels, consideration should be givento (1) channels that sense a set of variables differentfrom the principal channels, (2) channels that useequipment different from that of the principalchannels to sense the same variable, and (3) channelsthat sense a set of variables different from those ofthe principal protection channels using equipmentdifferent from that of the principal

IEEE Std 603-1980 includes criteria substantially similar tothe foregoing IEEE Std 279 requirements, and is endorsedby Regulatory Guide 1.153 as an alternative.

7.1.2. Additional Agreed Bases

The applicant may have agreed to use additional standardsor conform to regulations or design techniques that are notdirectly required by the sources mentioned above. Thesebases should be identified.

7.1.3. Applicant's StatementsI

The applicant may have made statements in SAR text thatcertain standards would be used or that certain designtechniques would be used or would be avoided. Forexample, an applicant may voluntarily commit to avoidingthe use of interrupts and multitasking operating systems.Commitments that have or could have a material effect onthe outcome of the analysis should be identified.

7.2. Design Architecture

The points of the applicant's design that are salient todefense-in-depth and to the separation of the design intoindependent, diverse subsystems should be described..Asystem block diagram, such as that demonstrated in theAppendix, is extremely helpful here. The echelons ofdefense should be identified, and any division intoredundant, independent divisions should be described.Relations between the echelons, and between the echelonsand subsystems such as diverse ATWS mitigationequipment or the remote shutdown panel, should bedetailed with attention to aspects important to the analysis.In parts of the design that use redundancy, the votingscheme should be described, particularly where it may haveasymmetries that could be single-failure vulnerabilities. Itshould also be noted where the applicant's designcommitments are being used to decide significant designissues rather than using applicant-supplieddesign details.

7.3. Intentional Design Diversity

Any specific diversity or design features intended by theapplicant to improve protection system performance in theface of CMF should be acknowledged.

17 NUREG/CR-6303

Section 8. Findings

8. FINDINGS

Findings should be presented in a sensible organization thatcould be used directly by license applicants to reducediscovered vulnerabilities in their reactor protectionsystems. Previous analyses have used an organizationsimilar to the following.

8.1. General Vulnerabilities

These are vulnerabilities that appear in a majority of casesstudied under Guidelines 10 and 11. Reducing these wouldprobably be considered a higher priority than reducingisolated, specific vulnerabilities.

8.2. Specific Vulnerabilities

Vulnerabilities found under Guidelines 10 and I 1 that occuronly during one or a few SAR Chapter 15 events arereported here. These might be considered lower prioritythan general vulnerabilities, depending upon the eventconsequences.

8.3. Evaluation of Diversity

This section contains an evaluation of how many events arepotentially detected only by one sensor. Since reactor tripand various ESF functions are initiated by different logicalcombinations of sensor signals, this findings sectiondiscusses diversity for all mitigation functions.

8.4. Shared Signals

This section reports the results of the analysis required byGuideline 12.

8.5. Special Findings

Any other findings that a responsible reviewer may havenoted during perusal of the design should be reported here.

9. AIDS TO PRESENTATION ORANALYSIS

Gralphical aids can be used to enhance the intelligibility of areport and their use is encouraged. Previous workers havefound two kinds of chartsý and a drawing to be particularlyuseful both in doing the analysis and in presenting theresults. Analysis charts aid the analyst by presentinganalytic decisions in a matrix format that permits failure-by-failure determination of system response. Vulnerabilitysummary charts show analysis results consolidated inmatrix form by design basis event versus signals andblocks. The system block diagram presents the systemarchitecture with only the interconnections of interest to theanalyst being displayed.

Examples of graphical aids are given in the followingsections, some of which have been taken from diversity anddefense-in-depth studies prior to the conclusion of the

regulatory review process. Since this is done forexplanatory reasons only, no conclusions should be drawnregarding the eventual resolution of apparent vulnerabilitiesin the subject reactor protection systems.

9.1. Analysis Charts

Two analysis charts are shown in Figures 1 and 2, one for apressurized water reactor and one for a boiling waterreactor. These charts differ in detail, but their commonpurpose is to record failed signals or blocks ("CMFgroups") systematically and to indicate the results of eachfailure. One analysis chart is prepared for each Chapter 15event studied. The top portion of the chart consists of lineslabeled with reactor parameters and columns labeled withsensors or blocks. The failure of a sensor or a block willprevent a reactor parameter signal from passing through thesensor or the block, and this is indicated by placing a zeroin the appropriate intersection of row and column in theupper half of the chart. If the column is followed to thelower half of the chart, the mitigation means required forthis event and for the CMF represented in this column aremarked either with a zero (meaning no diverse initiation) orthe number of the reactor parameter that does causeinitiation. The chart is marked for each sensor, block,parameter, and mitigation means relevant to the event andthen examined for zeros in the lower half. The lower-halfzeros represent a failure to initiate mitigation for thecolumnar CMF in conjunction with the Chapter 15 event,and if insufficient mitigation is initiated, a vulnerability hasbeen found. Insufficient mitigation exists if the sum ofmitigation means with non-zero initiators in a column isless than the applicant's required mitigation for the Chapter15 event, reduced by the effects of portions of the controlsystem that are postulated to continue operation. Ademonstration of the use of analysis charts is contained inFigure 3.

The analysis chart provides a stepwise method ofconsidering common-mode failures and their effects.However, it may be difficult for others to interpret theanalyst's work solely from the chart, so it should beaccompanied with a short narrative describing thereasoning behind the chart marking.

9.2. System Block Diagram

Two system block diagrams are contained in the Appendix,along with a discussion of how blocks were selected andwhat level of detail is appropriate. Since an applicant hasseveral purposes for preparing diagrams of a proposedprotection system, it is unlikely that there will be anapplicant system drawing containing the necessary detailfor CMF analysis but not overburdened with extraneousmatter. Arrangement into blocks also aids the analyst'sperceptions and presents the significant interconnectionsgraphically. Guidelines 6 through 9 require that input andoutput connections be determined for each CMF taken inconjunction with SAR Chapter 15 events, and it is tediousand inefficient to have to search through several drawings

NUREG/CR-6303 .18

Section 9. Aids to Presentation

each time. Also, the system block diagram makes theanalyst's view of the system clear to readers of the analysisresults, so that analyst misperceptions can be corrected byknowledgeable reviewers. In spite of the effort involved,making an accurate system block diagram is recommended.

9.3. Vulnerability Summary Charts

There are potentially about 20 or 30 events to analyze,which result in an equal number of analysis charts.Vulnerabilities documented on the analysis charts can betransferred to a Vulnerability Summary chart, of which twoexamples are shown in Figures 4 and 5, for a PWR and aBWR respectively. These examples are from analyses inprogress, before resolution of vulnerabilities has occurred, aprocess beyond the scope of this discussion. Showing theseexamples after the resolution process has been completedwould be uninstructive.

It is also possible to summarize vulnerabilities discoveredduring analysis of type 3 failures discovered underGuideline 12. A summary chart for such a purpose is shownin Figure 6. This chart, too, is presented prior to thevulnerability resolution process.

19 19 NUREG/CR-6303


Event Number aTitle "

00P

Reactor Parameter

a.,

cn-uUO)

0.

in-u

E

LLC,w

E

LLu)

w

En

2-E

0.f

(nCL.J0I--3

0_n0

<CM

< U)

.0

oj)

En

Z 1)

cmEn

CL chZU) -

Table NumberLEGEND:Blank - not involved oraffected0 - not available due to CMF1 to 23 - initiating parameter

1 High Startup Neutron Flux

2 Overtemperature 0J - 0

3 Overpower 0 _ 0

4 Low Coolant Flow

I I I I I-I IIIndicates that failure of the global trip 1 11subsystem inhibits protective actioncaused by these parametersE

5 Low RCP Speed 11 .6 High Pressurizer Sensors, switches, and

High RCP Bearin blocks that may fail

/1 Indicates that failure of the global tripsubsystem inhibits protective actioncaused by these parameters0-",- 1t1-4-t

01 1 1z I t I~ I8 High Inter. Neutron Flux

I

I I

414t9t114-9-t-4-9 High Power Neutron Flux Comment linesr. . . . . . . . . . .10 High + Flux Rate

11 Low Pressurizer Pressure f _

12 High Pressurizer Pressure13 Low SG Level__114 Hh SG Level - Plant parameters with -14 High SG Level -- * ID numbers15 Low Steam Line Pressure

16 Neg. Rate SL Pressure

17 High Hot Leg Temp. _

18 Low Cold Leg Temp. _I

19 Low Startup FW Flow

20 High Cont. Pressure

21 Low CMT Level Failure ID numbers:]

22 Low Tavg _

23 Low Pressurizer LevelMitigation 1 2 3 4 5 6 7 8 9 10 11_Automatic Reactor Trip 14/90Safeguards Actuation Signal A zero in the lower

1st Stage ADS Valve Signal section means that indicated

IRWST injection N mitigation (reactor trip) fails if

Main Feedwater Line Isolation - failure 5 (global trip) occurs

RCP Trip Even if RT Group 1 fails, the L

CMT Injection reactor will trip on diverse

Auto. Depressurization System parameters 14 or 9Turbine Trip I

Steam Line Isolation

SG Blowdown IsolationContainment Cooling

Startup Feedwater Isolation

Passive Residual HeatRemoval Mitigation systems

Accumulator Injection ,_ _

CVCS Isolation _

Block Steam Dump _

Letdown Line Isolation [iA single common-mode failure and its consequences are represented by a column of the chart. The sensorchannel or block that fails is indicated at the top of the column. The failure is indicated by at least one 0 in thecolumn on the upper half of the chart. A consequential failure of a mitigation system is indicated by a 0 in thecolumn on the lower half of the chart, where the mitigation system is at the left of the row. If a number (not 0)appears in the lower half of the chart, it means that the mitigation system of that row will initiate with the plantparameter indicated by the number, despite the CMF of the column.

Figure 1. Pressurized Water Reactor Analysis Chart

NUREG/CR-6303 20

Section 9. Aids to PresentationGE SBWRA

Event NumberTitle

Reactor Parameter

Table Number

LEGEND:Blank-not involved oraffectedO-not available due to CMF1 to 23-initiating parameter

1 Low RPV Water Level

2 High RPV Water Level

3 High RPV Pressure

4 Low RPV Pressure

5 High Drywell Pressure 1 Indicates that failure of the TLU block will cause incorrectvalues of the associated parameters to be transmittedR MRIV• •. In_• •

7__HighSuppr._PoolTemp ___________

8 Low Suppr. Pool Level 0 -

9 High Neutron Flux{Indicates that a failure of the condenser10 Short Reactor Period -- vacuum sensor will fail to signal loss of

11 Low GDCS Pool Level condenser vacuum12 High Basemnat Temp 0O11'

13 Turbine Stop Valve Close

14 Turb. Inlet Pressure Low

15 Main Condenser Vacuum 0ai_

16 High SL Flow

17 High SL Radiation Comment Lines

18 High Contmnt Radiation_________________ - Plant parameters - __________

19 High Area Radiation P with ID numbers ]20 High Area Temp wihI ubes

21 Low CRD Pressure

22 Manual DPV Actuation

23 Manual GDCS Actuation

Mitigation

Automatic Reactor Trip 1

Close MSIVs Mitigation Systems LReactor Blowdown, SRVs.

Reactor Blowdown, DPVs

GDCS Initation

GDCS Deluge Valves Even with a failure of the condenser vacuumI

Operate ICS Valves sensor, MSIVs will still close by low water

LD & IS Valves Operate I _________

SLCS

A single common-mode failure and its consequences are represented by a column of the chart. The sensorchannel or block which fails is indicated at the top of the column. The failure is indicated by at least one 0 inthe column on the upper half of the chart. A consequential failure of a mitigation system is indicated by a 0 inthe column on the lower half of the chart where the mitigation system is at the left on the row. If a number (not0) appears in the lower half of the chart, it means that the mitigation system of that row will initiate with theplant parameter indicated by the number despite the CMF of the column.

Figure 2. Boiling Water Reactor Analysis Chart

21 NUREG/CR-6303

Section 9, Aids to Presentation

Event Number 15.2.4Title: Inadvertent Closureof All MSLIVs

Reactor Parameter

COC

Z >

7a-)

a-vj 0)

> Zn

C-0

0-Cn

0,-JCn 3:I-

0 F- Lua-

C')U)D

(D0

0CD)

0~ U)

0)

.C

n0 U)

Table Number 15.2-8

LEGEND:Blank-not involved oraffectedO-not available due to CMF1 to 21-initiating parameter

1 Low RPV Water Level 0 0 02 High RPV Water Level

3 High RPV Pressure 0 0 0 0

4 Low RPV Pressure

5 High Drywell Pressure

6 MSLIVs Close 0 0 0 0

7 High Suppr. Pool Temp

8 Low Suppr. Pool Level

9 High Neutron Flux 0 010 Short Reactor Period

11 Low GDCS Pool Level

12 High Basemat Temp

13 Turbine Stop Valve Close

14 Turb. Inlet Pressure Low

15 Main Condenser Vacuum

16 High SL Flow

17 High SL Radiation

18 High Contmnt Radiation

19 High Area Radiation

20 High Area Temp

21 Low CRD Pressure

Mitigation

Automatic Reactor Trip 9* 3* 6 6 6* = ARI

Close MSLIVs

Reactor Blowdown, SRVs

Reactor Blowdown, DPVs

GDCS Initation

GDCS Deluge Valves

Operate ICS Valves 1* 1 6 6 6* = diverse actuation (L2)

LD & IS Valves Operate

SLCS

Figure 3. Use o1 Analysis Charts

NUREG/CR-6303 22


(nCMF LVulnerability Summary M 2

Chapter 15 Event

a-

rcnx U)

U)

U)

w

C14E

U)LI.U)LU

CMF VulnerabilitySummary

C=L E

U)0-0

E

CU)

LU)>

HU)

C'j<U

-U)<U]

0

-JC:

0 caM 0

0.-

00

E

U)

ZU) ZU)n

Legend:blank - not involvedT - Trip vulnerabilityE - ESFAS vulnerability

15.1.2 - FW Sys. Malfunction thatResults in an Inc. in FW Flow E E T E E E15.1.4 - Inadvertent Opening of aSG Relief or Safety Valve E T E E E

15.1.5Steam System Piping Failure E T E E E15.1.6 - Inadvertent Operation ofthe PRHR System E E T E E E15.2.2 through 15.2.5 - TurbineTrips T15.2.6 - Loss of AC Power to thePlant Auxiliaries E T E E E

15.2.7 - Loss of NormalFeedwater Flow T E E E

15.2.8 - Feedwater System PipeBreak E E T E E E

15.3.1 - Partial Loss of ForcedReactor Coolant Flow T15.3.2 - Complete Loss of ForcedReactor Coolant Flow T

15.3.3 RCP Shaft Seizure(Locked Rotor) T

15.3.4RCP Shaft Break T15.4.1 - Unc. RCCA Bank Wd.from a Subc. or LP. Startup T T T1.5.4.2 - Unc. RCCA BankWithdrawal at Power T15.4.3RCCA Misalignment T15.4.4 - Startup of an InactiveRCP at Inc. Temp. T T T15.4.6 - CVCS Malfunction thatRes. in Dec. in Boron Conc. E E E E E E15.4.8 - Spectrum of RCCAEjection Accidents T T E E E T15.5.2 - CVCS Malfunction thatInc. Reactor Coolant Inventory E E T E E E15.6.1 - Inad. Opening of a'PrzrSRV or Inad. Op. of the ADS E T E E E15.6.3SG Tube Rupture E E T E E E15.6.5LOCA E E T E E E

Figure 4. Sample Pressurized Water Reactor Vulnerability Summary Chart

23 NUREG/CR-6303


0CLZCMF P

Vulnerability Summary aLL

Chapter 15 Event

Cc

CU

6)C

>0

Vulnerability Summary

I-0

-jC',

w02

a)E0 G

C:0

0

2 U)

0

U--J

C,CCaVi

6

CD

CD

0)

0

Pl0cl)C:

CD(D

LEGEND:

Blank-not involved

T-Trip Vulnerability

E-ESFAS Vulnerability

15.1.2-Feedwater ControllerFailure-Maximum Demand

15.1.3-Pressure RegulatorFailure-Open

15.1.4-Inadvertent Opening ofan RPV Relief or Safety Valve

15.1.6-InadvertentRWCU/SDC Operation

15.2.1-Pressure RegulatorFailure-Closed

15.2.2-Generator LoadRejection

15.2.3-Turbine Trip

15.2.4-Inadvertent MSLIVClosure

15.2.5-Loss of CondenserVacuum

15.2.6-Loss of AC Power tothe Plant Auxiliaries

15.2.7-Loss of NormalFeedwater Flow

15.5. 1-Inadvertent Startup ofan Isolation Condenser

15.6.2-Small Break ofInstrument Line

15.6.4-Steam Pipe Break EOutside Containment

15.6.5-LOCA Inside EContainment

15.6.6-Feedwater Line BreakOutside Containment

Figure 5. Sample Boiling Water Reactor Vulnerability Summary Chart

NUREG/CR-6303 24

ESF Subsystem

Reactor Parameter

C,,0-0

0 0

-n

-00n

0

-4V

0

0

Cr=3

0

C/)C:-n,

0I

0

C/)0

Cn

-0

CD

0

Low Pressurizer Pressure 1 X ___

Low Comp. Steam Line Pressure 1 X _ ....X _...

Low-1 Tavg 1 x ..........Low-2 Tavg 1 X Xx _

Low-2 Pressurizer Level 1 X X .. XLow SG WR Level 1 X2 X3 X X5High Hot Leg Temp. Thot 1 X2 X3 X5

Hig h N eg. R ate S L P re ss ure 1 X _:_:.:::•ii•:i:•!:

High Pressurizer Level 1 X X --

Low Cold Leg Temp. Tcold 2 X ...High-i Cont. Pressure 2 X ..........XLow-i CMT Level 2 Xl __

High-2 Comp. SG NR Level 2 X X X __ X X XHigh RCP Bearing Temp. 2 XLow SG NR Level 2 ---------------------------------- X4Low Startup Feedwater Flow 2 - X4"S" Signal X X X X X X XCMT Injection I xiADS 1st Stage X X

Manual FW ISO X xReactor Trip x

0~

0

0.

Note: An X with a number must be coincident with the same numbered Xto actuate the system (e.g., both Xl's must be asserted to initiate ADS).

Figure 6. Summary Chart for Analysis of Type 3 Failures

REFERENCES

Branch Technical Position, "Digital Instrumentation andControl Systems in Advanced Plants," HICB, 1993.

Hanauer, S. H., and Walktr, C. S., Design Principles ofReactor Protection Systems, ORNL-NSIC-51, OakRidge National Laboratory, September 1968.

Hanauer, Stephen H., "A Review of Diversity in TripUnits," Letter Report, EG&G Idaho, Inc., February1990.

Kelly, John P. J., McVittie, Thomas I., Yamamoto, WayneI., "Implementing Design Diversity to Achieve FaultTolerance," IEEE Software, July 1991, pp. 6 1- 7 1.

Knight, J. C., and Leveson, N. G., "An ExperimentalEvaluation of the Assumption of Independence inMulti-Version Programming," IEEE Transactions onSoftware Engineering, Vol. SE-12, No. 1, January1986, pp. 96-109.

Mahmood, Aamer, and McCluskey, E. J., "ConcurrentError Detection Using Watchdog Processors-ASurvey," IEEE Trans. on Comm., Vol. 37, No. 2,February 1988, pp. 160-174.

NUREG-0493, A Defense-in-Depth and DiversityAssessment of the RESAR-414 Integrated ProtectionSystem, United States Nuclear RegulatoryCommission, March, 1979.

NUREG-800, Standard Review Plan for the Review ofSafety Analysis Reports for Nuclear Power Plants,United States Nuclear Regulatory Commission.

NRC Regulatory Guide 1.70, Revision 2, Standard Formatand Content of Safety Analysis Reports for NuclearPower Plants, September 1975.

Palomar, J. V., Preckshot, G. G., and Wyman, R. H., ADefense-in-Depth and Diversity Assessment of theGeneral Electric ABWR Protection System, LawrenceLivermore National Laboratory, UCRL-ID- 114000,April 30, 1993a.

Palomar, J. V., Preckshot, G. G., and Wyman, R. H., ADefense-in-Depth and Diversity Assessment of theWestinghouse AP-600 Protection System, LawrenceLivermore National Laboratory, Draft Report,September i, 1993b.

Preckshot, G. G., A Defense-in-Depth and DiversityAssessment of the General Electric SB WR ProtectionSystem, Lawrence Livermore National Laboratory,Draft Report, July 30, 1993a.

Preckshot, G. G., Reviewing Real-Time Performance ofNuclear Reactor Safety Systems, NUREG/CR-6083,1993b.

Preckshot, G. G., "Assessment of IEEE Standard 796-1983'IEEE Microprocessor System Bus'," Technical LetterReport, Lawrence Livermore National Laboratory,January 15, 1993c.

Regulatory Guide 1.97, "Instrumentation for Light-Water-Cooled Nuclear Power Plants to Assess Plant andEnvirons Conditions During and Following anAccident," NRC, Rev. 3, May 1983.

Regulatory Guide 1.153, "Criteria for Power,Instrumentation, and Control Portions of SafetySystems," NRC.

SECY-91-292, "Digital Computer Systems for AdvancedLight Water Reactors," NRC, September 16, 1991.

SECY-93-087, "Policy, Technical, and Licensing IssuesPertaining to Evolutionary and Advanced Light-WaterReactor (ALWR) Designs," NRC, April 2, 1993.

Staff Requirements Memorandum, "SECY-93-087, Policy,Technical, and Licensing Issues Pertaining toEvolutionary and Advanced Light-Water Reactor(ALWR) Designs," July 21,1993.

27 NUREG/CR-6303

APPENDIX-BLOCK EXAMPLES

Choosing blocks in a design is sufficiently important thatthis appendix provides two system block diagrams anddiscusses the reasons why choices were made in thesecases. The first block diagram was prepared for an analysisof a BWR protection system that included intentionallydiverse (non-digital) logic elements as alternate trippathways to digital elements. To emphasize this, the digitalelements are drawn in the upper-left quadrant of the (2-page) system block diagram, while the intentionally diverseelements occupy the lower-left quadrant. The reasoning inthe report was stated as follows:

Choice of blocks

The RPS consists of the assembly shown in (thefollowing) System Diagram. Of the objects shown inthat diagram, only DTMs, TLUs, and the EMScontain software.

Blocks that are independent

The standard for independence between twosubsystems as defined above is that they must differsignificantly in parameters, dynamics, and logic. Iftwo such subsystems perform similar functions buthave differing inputs (different parameters beingsensed) combined by different logic, it is assumedthat the two subsystems do not have a common failuremode. This assumption is reasonable since it isimplicit that the programs being run will differ intiming and logic because of the differing inputs andprocessing code. By this standard, DTMs withdiffering inputs will differ from each other, and TLUswith differing inputs will be independent of eachother.

Blocks that are identical

In contrast, subsystems with the same functions,hardware, and similar inputs (as exist in

functionally identical subsystems in separateprotection system divisions) are assumed to havecommon failure modes due to potential replicatedsoftware errors. These subsystems are substantiallythe same in parameters, dynamics, and logic. Suchfailures need not occur at identical times, but merelyclose enough that surveillance is insufficient to detectthe failures in time for effective repair. (Thisassumption implies common-mode failures in DTMsof similar inputs, ThUs of similar inputs, and theEMS.)

Effect of the operating system

The operating system, which is c ommon to allsubsystems in this design, will not be included as asource of common-mode software failures. It isassumed that the operating system as described by(the vendor) is simple enough that failures are relatedto service demands and that service demands aredistributed differently enough in subsystems definedas dissimilar (above) to exclude the operating systemas a separate cause of common-mode failure.Consequently, any common-mode operating systemfailures are subsumed by (the previous paragraph).This assumption is not valid if (the vendor) uses acomplex, multitasking operating system or uses morethan a simple clock-updating timer interrupt.

The system block diagram shows the detail of whichsignals go to which blocks and through the EMS, which isconsidered a potential site of common-mode failures.Internal logic is not shown because it is irrelevant for thepurposes of the analysis.

29 29 NUREG/CR-6303

Appendix

EMSMux

IMLVDsition switches

CR0 Pre ssure

M - 1111- I~~Fin DT M. In - - - -T L-C 11WIDTM othrrdivisions L

-z powKWUMo ARNM TripC LU. Byposo

- F--

rMultiplexed Sensors

N RPVnnr nn wr Ill

SRPV wd mowtr Il

GI•CS pool [evelflrywPI hsocprrn, tomp

'rywPII prcnc•p r

RPV dome pressureS-,,. D2 I T--P

Supr. Pool LevelCRrl (rharninn PrpznrreJ

Main flnnrrnpnnnr Var

Turbine Inlet PressureIUl1 Frlnw

COthpr I F) &Iq q--mnar

Cot innmnr MContainment Rad Mon.

CazC

WrIittssL DTM 1

TAPco rjnt~t eraLicti

Y7z~F DTM -

L___Vill, LU.

Dj~vrywal DTM .

From, DT Mein Lothrer diviontln~1

1Fromt 0TMss ~ F~ In=__________othr. d ormbone-b..-I

4-~1MS~wMSLlVs

~&~::er I DTM KMoo ýU

Cross ConD

From ATM, _TS oner divisior - DLU

Squbs M IP VI

F l D - M Iso I IIW2l RPV w.r0wf vIRPV dnm# r, tr

tPRMSJ SRNM

NMS

APRM

ToD LU.LU

W L ATMTo

-_ PLU,

Iv/ .... - . r

Fromn AT Ms inr DLUother divisionr

L SRVs I-In Il

TW S .-

For ATM'm iLother d-on L

LI ATM LD&IS

Places Bypas

!M I Cnntr l AIPi

W•L IATM Byp.• UnWSAit

Figure A-1. Sample BWR System Block Diagram

NUREG/CR-6303 330

RPVWater Level<L1

Places

SSever al Ini~a~nfi s S

" IFW Runback"FMCRDs

Fromo . -- .< s

Figure A-1. Sample BWR System Block Diagram (continued)

31 NUREG/CR-6303

Appendix

This page intentionally left blank.

NUREG/CR-6303 332

Appendix

The second block diagram was prepared for an analysis of aPWR protection system that was constructed byinterconnecting a number of superficially similar IEEE 796bus computer systems. These computer systems appear tobe similar because they consisted of standard printed circuitcard modules plugged into IEEE 796 backplanes. Thecomputer systems, however, differed significantly infunction performed, detailed configuration, and purposewithin the architecture. The reasoning that was used in thereport for the choice of identical or diverse blocks wasstated as follows:

Choice of blocks

The IEEE-796 standard bus is used as theinterconnect between the logic cards which make upthe various subsystems of the protection system.Communication between subsystems is carried on byother means. Therefore the blocks used in thisanalysis consist of the subsystems, where eachsubsystem uses a single IEEE-796 bus forinterconnection of the logic cards of the subsystem.NUREG-0493 "Measured Variable Blocks" and"Derived Variable Blocks" cannot usefully beidentified in this design.

This choice is made because a subsystem so definedappears to be the smallest block into which the(reactor) protection system can be subdivided withcredible restrictions on block-to-block faultpropagation. Hardware or software failure of anyprinted circuit board in an IEEE-796 chassis isassumed to fail the entire chassis. It is assumed thatsome failures are not detected by the watchdog timer.For additional information on the reliability of theIEEE-796 standard bus, see Preckshot 1993c. In thebalance of this document, unless otherwise'stated,"subsystem" is used in the (vendor's) sense toidentify an IEEE-796 bus system.

Blocks that are independent

The standard for independence between twosubsystems as defined above is that they must differsignificantly in parameters, dynamics, and logic. Iftwo such subsystems perform similar functions buthave differing inputs (different parameters beingsensed) combined by different logic, it is assumedthat the two subsystems do not have a common failuremode. This assumption is reasonable since it is

implicit that the programs being run will differ intiming and logic because of the differing inputs andprocessing code.

Blocks that are identical

In contrast, IEEE-796 subsystems with the samefunctions, hardware, and similar inputs (as exist infunctionally identical subsystems in separateprotection system divisions) are assumed to havecommon failure modes due to potential replicatedsoftware errors. These subsystems are substantiallythe same in parameters, dynamics, and logic. Suchfailures need not occur at identical times, but merelyclose enough that surveillance is evaded. (Thisassumption implies common-mode failures in the RTgroups, ESF groups, Engineered Safety FeaturesActuation Subsystems (ESFAS), PLCs, Trip Enable,or Global Trip subsystems of each division; failure ofthe ESFAS would disable automatic initiation of ESFequipment, while still allowing manual initiations; aPLC failure would disable automatic and manualinitiation of all ESF equipment; failure of the TripEnable Subsystem would incapacitate automaticpartial reactor trips from the Reactor TripSubsystems, but Global Trips and manual trips wouldstill be available; a common mode failure of theGlobal Trip subsystems prevents any automaticreactor trip, while still allowing manual trip.)

Effect of the operating system

The operating system, which is common to all IEEE-796 subsystems in this design, will not be included asa source of common-mode software failures. It isassumed that the operating system as described by(the vendor) is simple enough 11 that failures arerelated to service demands and that service demandsare distributed differently enough in subsystemsdefined as dissimilar in section 3.6.3.2 to exclude theoperating system as a separate cause of common-mode failure. Consequently, any common-modeoperating system failures are subsumed by section3.6.3.3. This assumption is not valid if (the vendor)uses a complex, multitasking operating system or usesmore than a simple clock-updating timer interrupt.

11 See Preckshot 1993b for a discussion of complexity.

33 NUREG/CR-6303

Appendix

IPC Inputs -

Son'g Ho. 1,onft.

pig- Hallis N-oo R t. in

Po-. Hon. N--Oo Rt. so x

H'A Bown -o~ Tell, l .HCP 0 0-olqA W..~ T-np. 0 .HO

0 C SWiN. Wow' ImP .

HCP D B..ing Woo' Tosp. O .P-.i, C-oolnt Fý A.HoPso Cog... Pg,.Po. - Cý.. R-. CHP.-o Coo-s R-o DC0.,so P-W n 08Cio; ogOs -P" .2

SC , A a .1. bog -o.,SGB AI NoA 1.0SGioi~gn A FI011W.I88P

SC 8 WA 00 8

So.... A~~o'1.CoS-.nn P-,o~ 0Cwo.. .stag -lo., .

X Xx . x Ix x xx x xx IT xx x xr-X Xx xx xx xxx

Xx x x xX X X. x -x x xI X. IX X Xx .X X I. x xX X Xx x x xx x x xx xx xx xX XI Ix xx xx

II

8St*1

F

F

B

I* C

S* 10

8i8~.

- ~ ~ T A..o To.- Sxxos

*Gs. oons, GolCo.n, 16 A7o 1.00. S0To A. ~ lSbasi, eN V3 o~t.t

4 P. Eoid ... ino TosA A& t~,ooA..Coss..w S.*,. M oo O ASB

0.50~D. IVfgs 00

ET f / I- F- -ooa In - SF ~TEFmS,AADr..D..O.A.."Co's, SoS. 3 Sbto. lo- Sob.~a,,

D, 13so o 10.0

Lý-ftfigs &I.I A2C

Flo-0,1070,6poOO0o

- os - -,. AM Von o U-O. DLUoo.

11.8~L~~ ~1

A C"IsS..ai L.. lhoy

A

FPi- ESF G.• oI S..Sl•,'s

I.. A B C D

I II I

Fig. ESP Go.- 2 Soboso.Ogigo. A B C D)

lII II

f-os ESf GCoo'I SIoniialosD_-o A B C 0

lII II

Figure A-2. Sample PWR System Block Diagram

NUREG/CR-6303 34

Appendix

RPS TRIP SIGNALS 17-0

*A' S--o Bone

Loos,. C-1- w- Speeod

,6 P--~ W- osor4g' ROP 0ow," lsw,, 4A IM Iif

lie? Cnis -wn 1in,w

LA. 7-0/

How Pwiv ., R~ossP W

Los, iso , P. BnI+0 P.os Bog ?ossIPsl,-S P...BW..14 IASLP)

Nlign o.O FL~ BonoP P, o, BOCg.

.~' Pwsa .. I~Sb

sox Awei to. IOC

og TI,. RosiTloP.Be o, O

R t. Stgp ADS Vs/ow

ESF WMAIfON SIGNALS

doi.n blow Ad,bW. Woos

Lo-?? owr

-,wpso-nw~o~I.. -wPo. .i I- .ArIw/

FAA" hot rog o-W-,n*,

Frgh VitA tww1w, -11 ~n00. -stP SC NRB -1o

Ow.A o niofO

,Z'A~~oow~aO

IPC13311? WAPS lhltow-1VA~ a ConA MW 4.DoonOWMn SAB Ch0OW 7, liOtsnwogon a Con14/AO

2) I ii o.. -1o in - wo Mfswo Ilso SPnwo W.5,.b.oy~ , IEEE 796 Sim.

31D~ Th ilsont boos. A s- onOf Rff -Ng lifts wp,,ni, On. 1E-

E-isiwOCA.M C .W.,

aFIEEE?M Mwnnnilim bsolOs/on5) This &ongVss won wisc5 fo, *A Deton-s.-Dsp w aDMWl

I=os? M--nw i.1 - o.go IkP-0 N~own

ESEA Eg.os SoVt Foso.. CESFAS Er4,,oswwo S.I.V Fossuol,. A-goo Sbosoo-I-SF KiO Iý-o Ro.cc .. g,.. Conno C/owliPC Atsgs -/ooo CS...MlCB Moni C.nno R-o.III t&,oi,, Ihsr ioinVO .w4 NonoosRogPOLC T~~A-o Logs Con...,COPS 0.,O,. so oosw SY.-nRSH . l==not SO1tow=7oRi ,? 101w ,,pR. PowSSC S-o' Con-lUY ITIoswnlg

WFI ý WA.-Bn

1A:O loot. of..ogT B..

W1ISNG LEGEND ____

Dglw Swiss

F,-o Ols, Co--n~~n.o to/A -

M~o/gis F.-, OnSA -

F- CSF 0C,-2 S-0e-

Ac- A ESFAC RSR MUXLto, B.. I Logs Ba 2

4 4

MCR MUXtogaeB.a 7

DAS

4

I/CR MhAplio,, To ,5Cotb

At H., 777 BI Ba 777

Sol, 2M.-L'.f'.o C-osi.

?Aoon.oV 00ý;

1. D-.m ContotFoo 13-. ~o~o

Mti U~olAntoss,S */i~n

BtADo.,s7 ?o?7

-log MOG SowPo To~bmA

SN/I 114*1Ac s.. CUTASTitoF Al RCA'sC-fontO lo'.t -s

Ow. NTSI to.. VAO-

SG LmnAH., Log Tw'-~~~

RCS Hoft Log/rn

Figure A-2. Sample PWR System Block Diagram (continued)

35 NUREG/CR-6303

NRC FORM 335 U.S. NUCLEAR REGULATORY COMMISSION 1. REPORT NUMBER(2-89) (Assigned by NRC. Add Vol., Supp., Rev.,NRCM 1102, end Addendum Numbers, If any.)3201.3202 BIBLIOGRAPHIC DATA SHEET NUREG/CR-6303

(See insrrucrions on the reverse) UCRL-ID-1 19239

2. TITLE AND SUBTITLE

Method for Performing Diversity and Defense-in-Depth Analyses 3. DATE REPORT PUBLISHED

of Reactor Protection Systems MONTH YEAR

December 19944. FIN OR (RANT NUMBER

L1867

5. AUTHOR(S) 6. TYPE OF REPORT

G. G. Preckshot7. PERIOD COVERED (InclusiveD.ates)

8. PERFORMING ORGANIZATION - NAME AND ADDRESS ([i NRC. provide Division, Officeor Region, U.S. Nuclear Regulatory Commission, and mailing address: it conorator, providename and mailing addresLs)

Lawrence Livermore National LaboratoryUniversity of CaliforniaLivermore, CA 94551

9. SPONSORING ORGANIZATION - NAME AND ADDRESS (If NRC, rype "S ,,e e, abe, ifconrrerw~pronideNRC0i~ieioo, Offce or Region. US. Noviee, Ret,,iarov Cornni,,,ion.9. SPO NSO R I NG 0OR GAN I ZAT ION - NAM E A ND A DO R ESS Iff NR, typ "Sam as above "- it contractor provide NRC Divisin, Offie or Region, U-S Nuclear Regulatory Commisin,

and mailing address.)

Division of Reactor Controls and Human FactorsOffice of Nuclear Reactor RegulationU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001

10. SUPPLEMENTARY NOTES

11. ABSTRACT (200 words or leai

The purpose of this NUREG is to describe a method for analyzing computer-based nuclear reactor protection systems thatdiscovers design vulnerabilities to common-mode failure. The potential for common-mode failure has become an importantissue as the software content of protection systems has increased. This potential was not present in earlier analog protectionsystems because it could usually be assumed that common-mode failure, if it did occur, was due to slow processes such ascorrosion or premature wear-out. This assumption is no longer true for systems containing software. It is the purpose of theanalysis method described here to determine points of a design for which credible common-mode failures are uncompensatedeither by diversity or defense-in-depth.

12. KEY WORDS/DESCR1PTORS (List words or phr ases that will assist researrhe,, in locating the report. I 13. AVAILABILITY STATEMENT

UnlimitedDivers ity 14. SECURITY CLASSIFICATION

Defense-in-Depth (rhis P•ge)

Analysis UnclassifiedSoftware (7his Report)

Unclassified15. NUMBER OF PAGES

16. PRICE

NRC FORM 335 12-891

Federal Recycling Program

N UM~kU/K--OiUi mOFiRuA TOK rPKrur4v uivrno I A YSTEMS-OF REACTOR PROTECTION SYSTEMS

UJiLMhIUIEK 1994

UNITED STATESNUCLEAR REGULATORY COMMISSION

WASHINGTON, D.C. 20555-0001

FIRST CLASS MAILPOSTAGE AND FEES PAID

USNRCPERMIT NO. G-67

OFFICIAL BUSINESSPENALTY FOR PRIVATE USE, $300