ML20197B302

Submits First Draft That NRC Staff Has Prepared in Support of Delveloping PRA Stds

ML20197B302
Person / Time
Issue date:	02/23/1998
From:	Mary Drouin NRC OFFICE OF NUCLEAR REGULATORY RESEARCH (RES)
To:	Cummingham M NRC OFFICE OF NUCLEAR REGULATORY RESEARCH (RES)
References
NUDOCS 9803110008
Download: ML20197B302 (66)

Text

T 4

j February 23, 1998 TO:

Mark Cunningham, Chief Probabilistic Risk Analysis Branch FROM:

Mary Drouin, Chief Risk Based Regulation & Reliability Section Probabilistic Risk Analysis Branch

SUBJECT:

PRA STANDARDS Attached is the first DRAFT that the NRC staff (with contractor sur port) has prepared in support of developing a PRA standard. The scope of the standard covers a Level 1&2; full power operation, low power and shutdown; and both internal and exterral events. This standard, as proposed, will set forth the criteria for applying risk assessment methodology to commercial nuclear power plants, and therefore, will define the various requirements needed in performing a PRA to support risk-informed applications. Specifically, the standard will provide the following:

Specification of the minimum requirements for performing each technical aspect of a detailed PRA.

Specification of the documentation necessary to provide traceability of the work.

Specification of the criteria to be used in a peer review to determine whether the required technical acequacy was achieved.

Specifica; ion of the credentials of the peer review team.

Since it is recognized that not every application requires a detailed PRA, there should also be criteria for spdfying where certain requirements are not necessary. Therefore, we have also included, as part of the PRA Standard, a process for determining which of the requirements are necessary and not necessary for a specific application.

Although the scope is for a full-scope PRA (as defined above), the attached DRAFT only I

addresses a Level 1 PRA for full-power operation including internal events (excluding internal e

fire events).

The attached DRAFT is very preliminary and only includes the following:

[hf 1.

Identification of the major PRA elements and their associated elements and sub-elements, and identification of the functional requirements for each element (this indicates the minimum level of detail proposed for the standards).

2.

Detailed notes by the authors indi:ating what requirements are proposed to be included

^m r--

e n &

9803110000 980223 PDR GRC NREB i

t PDR e

e 2

for the major PRA elements (except for systems analysis). The authors' notes are highlighted throughout to differentiate from actual text.

3.

An initial list of the necessary documentation for each PRA element.

4.

For systems analysis, the technical analysis requirements for each element are provided (this illustrates, generally, the maximum level of detail to which each PRA element may be written recognizing that not every element can or should be written to this detail).

5.

Fc. systems analysis, the peer review requirements are provided for some of the sub-elements (again to illustrate what is intended to be included).

6.

An initiallist of the credentials of the peer review team fer systems analysis.

The requirements (or notes) for a process in determining which of the requirements are necessary for a specific application are not included in the attached draft. The proposed process and requirements are being drafted and will be ready for your review in the near future, it needs to be emphasized again that the attached draft is prelimir ary, it only represents an initial set of ideas and provides you with an early roadmap of what the staff is proposing in developing PRA standards. It is anticipated that changes, will occur as the standards are being writ'er), revised and finalized. Numerous documents were used in the development of this draft.

Three documents, however, were the primary source of information and included draft NUREG-1602, the BWROG PSA Peer Review Certification Implementation Guidelines, and the EPRI PSA Guidelines.

A copy of this draft has been placed in the public document room. ::is anticipated that the

. ASME task group which is developing an 'ASME Standard on Risk Managoment for Nuclear Facility Applications" may use this document in their effort. It is expacted that this draft will help clarify our expectations regarding the scope and depth of a PRA standard and will facilitate the ASME PRA standard efforts and our goal to endorse and use such a standard, attachment: as stated Distribution:

PRAB Subject File File Center M.W. Hodges T. King J. Craig PRAB Stcff N. Chokshi G. Parry M. Rubin S.!ong M. Cheok PDR DOCUMENT NAME: G:\\ Mark 220.WPD Ta receive a copy of this document. Indicate in the boa: "C' = Cooy wrthout attachment / enclosure "E" = wooy with attachment / enclosure "N* = No copy OFFICE DST /RMB 1

1 NAME MDrohhg DATE 919ff98

/ /98

/ /98

//98

/ /98 OFFICIAL RECORD COPY (RES File Code) RES c2c. - /

I l

PRA Standard (Draft) i

-9 0

Y W

'-*"%m

Table of Cont:nts, Figurcs, Tables Table of Contents 1' INTERNAL EVE.VTS, FULL POWER OPERATION, LEVEL 1 PRA.

1-1 i.i Plant Information Sources 11 1.1.1 Technical Analysis Requirements....

1-1 1.1.1.1 Information identification and Collection........

. 1-1 1.1.1.1.1 Design (for the systems or equipment that relate to the required functions)....

1-2 1.1.1.1.2 Operational (beyond those aspects already covered above)

...... 1 -2 1.1.1.1.3 Maintenance............................ 1 2 1.1.1.1.4 Engineering 1.2 13.1.2 Plant Walkdowns

,... 1-3 1.1.1.2.1 Sequence / systems...

1-3 1.1.1.2.2 Human Reliability Analysis (HRA).

13 1.1.1.2.3 Containment..

1-3 1.1.1.2.4 Intemal flood (unique considerations).

1-3 1".1.2.5 Internal fire (unique considerations),.

1-4 1.1.2 Do- - txn Requirements.

14 1.1.3 Appw,... u. Requirements 1-4 1.1.4 Peer Review Requirements.

.1-4 1.2 initiating Event Analysis '

1-4 1.2.1 Technical Analysis Requirements...........

15 1.2.1.1 - Plant Response Understanding......

..........,1-5 1.2.1.2 Model Selection Criteria 1-5 1.2.1.3 Definition of Initiators 1-5 1.2.1.3.1 Loss-of-coolant accidents (LOCAs)....

..... 1-6 1.2.1.3.2-Transients -

1-6 1.2.1.3.3 Intemal Flood.

1-6 1.2.1.3.4 Intemal Fire.

.1-6 1.2.1.4 Selection of Initiators

.1-6 1.2.1.4.1 Plant-Specific Analysis..

1-6 1.2.1.4.2 Generic Analysis

.1-8 1.2.1.5 Screening Criteria.

... 1 -8 1.2.1.6 Grouping Criteria 1-9 1.2.2 Documentation Requirements.

1-9 1.2.3 Application Requirements 1-10 1.2.4 Peer Review Requirements.

1-10 1.2.4.1 Qualification of Peer Reviewers 1-11 1.2.4.2 Review Criteria..

1-11 1.3 Success Criteria 1-11 1.3.1 Technical Analysis Requirements 1 12 1.3.1.1 Definition of Core Damage.

1-12 1.3.1.2 Core Damage Prevention.

1-12 1.3.1.2.1 Safety function identification 1-12 iii PRA Standard. Draft (STANDARD.RV3)

I t

Tabb of Contents. Figures. Tables 1.3.1.2.2 Definition of functional success enteria 1 13 1.3.1.2.3 Identification of function and system relationship.

1-13 1.3.1.2.4 Determination of system success criteria 1-13 if 7 Documentation Requirements.

. 1-15 1.3.3 Application Requirements 1-15 1.3 4 Peer Review Requirements..

1 15 1.4 Accident Sequence Analysis 1-16 1.4.1 Technical Analysis Requirements

. 1-17 1.4.1.1 Model Selection Criteria 1-17 1.4.1.1.1 Faiailianty with Details of Plant Response 1-17 1.4.1.1.2 Model Type

. 1 17 1.4.1.2 Definition of Analysis Boundaries.

1 18 1.4.1.2.1 End States 1-18 1.4.1.2.2 Mission Times 1 18 1.4.1.2.3 Cond'tional Success Criteria 1-18 1.4.1.2.4 Extent of Modeling Functional Redundancy.

1 18 1.4.1.2.5 Connection of Sequence Events to Success Criteria and System Definitions 1-18 1.4.1.3 Model Construction Criteria 1-18 1.4.1.3.1 Definition and Ordering of Sequence Events 1-18 1.4.1.3.2 Definition of Event Sequences.

1 19 1.4.1.3.3 Screening and Grouping Criteria 1-20 1.4.1.3.4 End State Assignment Criteria 1-20 1.4.2 Documentation Requirements.

1-20 1.4.3 Application Requirements 1-21 1.4 4 Peer Review Requirements.

1-22 1.5 Systems Analysis 1-22 1.5.1 Technical Analysis Requirements 1 23 1.5.1.1 System Understanding.

1-23 1.5.1.2 ModelType Selection Criteria 1-24 1.5.1.3 Definition of Boundary Conditions of Analysis 1-25 1.5.1.3.1 System Success Criteria 1-25 1.5.1.3.2 System and Component Boundaries 1-25 1.5.1.3 3 Compenent Failure Modes.

1-26 1.5.1.4 System Dependencies and interfaces identification Criteria 1-28 1.5.1.4.1 System initiation. Actuation, and Operation 1-28 1.5.1.4.2 System Isolation. Trip, or Failure 1-29 1.5.1.4.3 System Capabiliiy 1-29 1.5.1.4.4 Shared Equipment 1-30 1.5.1.4.5 Subtle Interactions 1-30 1.5.15 Screening Cnteria.

1-31 1.5 1.5.1 Support System Screening Criteria 1-31

1. 5.1. 5.2 Component Screening Critena.

1-31 1 5.1.5.3 Failure Mode Screening Cnteria 1-32 1.5.1.6 Integrated Model Construction Criteria 1 32 1.5.1.6.1 Event Naming Scheme 1-32 a

PRA Standard Draft (STANDARD.R"3) iv 1

Table of Cont:nts, Figurss. Tabl:s 1.5.1.6.2 Model Linking 1-32 1.5.1.6.3 Modularization 1-33 1.5.1.6.4 Analysis interface.

1 33 1.5.2 Documentation Requirements.

1 33 1.5.3 Application Requirements....

1-34 1.5.4 Peer Review Requirements.

1 36 1.5.4.1 Qualification of Peer Reviewers.

1-36 1.5.4.2 Review Requirements 1-36 1.6 Human Reliability Analysis (HRA) 1-40 1.6.1 Technical Analysis Requirements.

1-41 1.6.1.1 Definition of Human Actions.

1-41 1.6.1.1.1 Pre-Initiator Human Actions 1-41 1.6.1.1.2 Post-Initiator Human Actions 1-41 1.6.1.2 identification and Selection of Pre-Initiator Human Actions 1-41 1.6.1.2.1 Test Related Human Actions 1-41 1.6.1.2.2 Maintenance Related Human Actions 1-42 1.6.1.2.3 Calibration Related Human Actions 1-42 1.6.1.3 Screening of Pre-Initiator Human Actions 1-42 1.6.1.3.1 Qualitative Pre-Initiator Human Action Screening 1-42 1.6.1.3.2 Quantitative Pre-Initiator Human Failure Event Screening 1-43 1.6.1.4 Evaluation and Quantification of Pre-Initiator Human actions 1-43 1.6.1.4.1 Activity Comprehension 1-43 1.6.1.4.2 Dependencies and Interfaces 1-43 1.6.1.4.3 Recovery Cnteria 1-44 1.6.1.5 Identification and Selection of Post-Initiator Human Actions 1-44 1.6.1.5.1 Response Related Human Actions 1-44 1.6.1.5.2 Recovery Related Human Actions

. 1-44 1.6.16 Screening of Response Related Human Actions 1-44 1.6.1.6.1 Qualitative Response Related Human Action Screenir g 145 1.6.1.6.2 Quantitative Response Related Human Action Gcreening 1-45 1.6.1.7 Evaluation and Quantification of Post-Initiator Human Actions 1-45 1.6.1.7.1 Sequence and Activity Comprehension 1-45 1.6.1.7.2 Human Action Types 1-46 1.6.1.7.3 Dependencies and Interfaces 1-47 1.6.1.7.4 Integration 1-47 1.6.2 Documentation Requirements.

1-48 1.6.3 Application Requirements 1-49 1.6.4 Peer Review Requirements.

1-49 1.7 Parameter Estimation.

1-50 1.7.1 Technical Analysis Requirements 1-51 1.7.1.1 A Generic Database 1-51 1.7.1.2 Parameter Estimation Understanding 1-52 1.7.1.2.1 Understanding the issues Affecting Parameter v

PRA Standard, Draft (STANDARD.RV3)

Table of Cont:nts. Figurts, Tcbles Estimation 1-52 1.7.1.2.2 Analysis Methods 1 52 1.7.1.3 Initiating Event Data Attributes...

1 53 1.7,1.3.1 Initiating Event Definitions 1-53 1.7.1.3.2 Data Applicability

. 1 53 1.7.1.3.3 Data Grouping.

1-53 1.7.1.3.4 Data Screening..

1-53 1.7.1,4 Equipment Independent Fai., e Data Attributes 1-54 1.7.1.4.1 Failure Data Definitions 1-54 1.7.1.4.2 Data Applicability 1-55 1.7.1.4.3 Data Grouping 1 55 1.7.1.4.4 Data Screening 1 55 1.7.1.5 Equipment Ccmmon Cause Failure Data Attributes 1-55 1.7.1.5.1 Common Cause Failure Definitions 1-56 1.7.1.5.2 Data Applicabili*y 1-56 1.7.1.5.3 Data Grouping 1 56 1.7.1.5.4 Data Screening 1-56 1.7.1.6 Out of Service Data Attributes

. 1 57 1.7.1.6.1 Out of Service Data Definitions 1-57 1.7.1.6.2 Data Applicability 1-57 1.7.1.6.3 Data Grouping 1-57 1.7.1.6.4 Data Screening

.1-57 1.7.1.7 Data Analysis Integration 1-57 1.7.2 Documentation Requirements.

1-57 1.7.3 Application Requirements 1 58 1.7.4 Peer Review Requirements.

1-59 1.8 Internal Flooding Analysis

. 1-60 1.8.1 Technical Analysis Requirements.

1-60 1.8.1.1 Plant Understanding.

1-60 1.8.1.2 Flood Sources Determination Criteria 1-61 1.8.1.2.1 Flood Source identifiation Criteria 1-61 1.8.1.2.2 Flood Source Screening Criteria 1-61 1.8.1.3 Flood Zones De(ermination Criteria 1-61 1.8.1.3.1 Flood Zone Identification Criteria 1-62 1.8.1 3.2 Flood Zone Screening Criteria.

1-62 1.8.1.4 Propagation Pathways Determination Cnteria 1-62 1.8.1.4.1 Propagation Pathways 1-62 1.8.1.4.2 Barrier Treatment.

1-62 1.8.1.5 Flooding Scenario identification and Screening Criteria 1-63 1.8.1.5.1 Effects or' Equipment.

1-63 1.8.1.5.2 Mitigation seatures.

1-63 1.8.1.5.3 Probabilistic Considerations.

1-64 1.81.6 Flooding Model Cntena 1-64 1.8.1.6.1 Model Development 1-64 1.8.1.6.2 Quantification and Recovery 1-65 1.8.2 Documentation Requirements.

1-65 PRA Standard, Draft (STANDARD.RV3) vi x

Table of Cont:;nts, Figurts, Tables 1.8.3 Application Requirements 1-65 l

1.8.4 Peer Review Requirements.

1-66 1.9 Internal Fire Analysis 1-67 1.9.1 Technical Analysis Requirements 1-67 1.9.2 Documentation Requirements.

1-67 1.9.3 Application Requirements

. 1-67 1.9.4 rear Review Requirements.

1-68 1.10 Intemal Events Ouantification 1-68 1.10.1 Technical Analysis Requirements 1-68 1.10.1.1 Model Selection Cnteria

.. 1-68 1.10.1.2 Truncation Criteria.

. 1-68 1.10.1.3 integration Criteria..

1-69 1.10.1.3.1 Model Integration

,,1-69 1.10.1.3.2 Quantification Process 1-70 1.10.2 Documentation Requirements..,.

. 1 70 1.10.3 Application Requirements 1-71 1.10.4 Peer Review Requirements..

1-72 1.11 Expert Judgemer,t 1 72 1.11.1 Technical Analysis Requirements.

1-72 1.11.1.1 Expert Elicitation 1-73 1.11.1.2 Expert Panels

. 1-73 1.11.2 Documentation Reqrirements...

1-73 1.11.3 Application Requirements 1..

1.11.4 Peer Review Requirements.

1 73 1.12 Analysis and Interpretation of Results 1-73 1.12.1 Technica' Analysis Requirements 1-73 1.12.1.1 Identify Significant Contributors.

1 74 1.12.1.2 Identify Sources of Uncertainty That impact Decision-making 1-74 1.12.1.3 Treatment of Uncertainty.

1-74 1.12.2 Documentation Requirements.

1-74 1.12.3 Application Requirements 1-74 1.12.4 Peer Review Requirements.

1-75 1.13 PRA Maintenance 1-76 1.13.1 Technical Analysis Requirements 1-76 1.13.1.1 Plant Familiarization 1-76 1.13.1.2 PRA Model Update 1-76 1.13.2 Documentation Requirements.

1-77 1.13.3 Application Requirements 1-77 1.13.4 Peer Review Requirements.

1 77 1.13.4.1 Qualifications of Peer Reviewers 1-77 1.13.4.2 Review Requirements 1-77 1

vii PRA Standard, Draft (STANDARD.RV3)

1. Intemal Events, Full Powsr, Level 1 (Draft)

1. INTERNAL EVENTS, FULL POWER OPERATION, LEVEL 1 PRA This report provides attributes for a Level 1 probabilistic nsk assessment (PRA) of a power plant for accidents initiated dunng full power operations. Full power is defined to encompass the operations that occur while the plant is at greater than 15% of rated power. A Level 1 PRA identifies and quantifies those accident sequences that could Icad to the onset of core damage. A summation of all such accidents leads to an estimate of the core damage frequency (CDF).

1.1 Plant Information Sources This first section will have a lead-in paragraph introducing this section as covering requirements related to familiarizing the analysts with those aspects of the plant design to ensure the as-built, as-operated plant is reflected in the PRA.

1.1.1 Technical Analysis Requirements This lead-in section will briefly address the following points:

The extent to which one must be familiar with the plant and hence, the information that needs to be collected, will depend on the scope of the PRA and the planned applications.

It is assumed for purposes of this portion of the standard, that the PRA is related to possible damage to the reactor core and containment for the at-power mode of operation, for intemal initiating events.

interest is limited to the prevention and mitigation of a release of radioactive material; not chemical releases, etc.

Overall goal of the familiarization process is to ensure that the PRA models, data, and assumptions adequately reflect the as-built, as-operated (current) plant.

1.1.1.1 Information Identification and Collection This section will be brief and:

Highlight the fact that the Aformation that is collected and used must be sufficient to relate how equipment unavailabilities/unreliabilities and human actions, singularly or in combinations, impact the ability to perform ne required functions to prevent and mitigate significant damage to the core or containment; Present the broad categories of information to be used, as shown below.

It will be noted that while this is the first element of the PRA process, it is an ongoing task throughout the entire analysis as questions get raised for which additional information must be collected.

it.will also be noted that this section provides an overview of the requirements related to the 1-1 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Events, Full Poenr, Level 1 (Draft)

I information collected and used during the plant familiarization process; additional details are found in each PRA element wnteup.

1.1.1.1.1 Design (for the systems or equipment that relate to the required functions)

This section will address the fact that the PRA needs to reflect the actual design of the plant includ'.sg r

the functions to be performed, the functional relationships among equipment including functional and hardware dependencies,' normal and emergency configurations of the equipment, auto and manual (human interfaces) attributes for operation as well as termination, equipment capabilities (flows, pressures...), etc.

Typical sources for these types of information should include P&lDs, one-lines, I&C drawings and information, the Safety Analysis Report (SAR), system descriptions and related design documents, spaciallayout drawings, etc.

1.1.11.2 Operational (beyond those aspects alrearly covered above)

This section will address the fact that the PRA needs to reflect actual operating procedures and practices used at the plant such as when and how operators interface with each system or equipment including monitoring of equipment operation. Also, the PRA needs to reflect the operating history of the plant and equipment (good and bad) as well as any significant human events.

Typical sources of these types of information should include Emergency and Abncrmal Operating Procedures (EOPs/AOPs) as well as normal operating procedures, training information, control room and local layout of operating and monitoring equipment / indications / alarms, scram and incident reports, control room logs, Licensee Event Reports (LERs), Tech Specs, etc.

1.1.1.1.3 Maintenance This section will address the fact that tlie PRA needs to reflect planned and typical unplanned tests

+

and maintenance activities and their relationship to the unavailability of equiprnent (is equipment out-of-service?, frequencies, durations...) as well as historical information.

Typicalinformation sources should include test and maintenance procedures, maintenance records, Tech Specs, etc.

1 1.1.1.4 Engineering There are engineering aspects related to the design that are also typically required not only to accurately reflect the plant, but to also achieve a best-estimate result. For instance:

The PRA needs to reflect the design margins in the capabilities of the equipment, operating environment limits of the equipment, expected thermal hydraulic plant respoilse to different states of equipment (such as for estabbshing success criteria), etc.

This information should come from design basis-related documentation, SAR accident analyses, PRA Standard, Draft (STANDARD.RV3) 1-2

1. Intemal Eysnts, Full Power, Lt n; 1 (Draft) additonal thermal hydraulic analyses, engineering calculations, equipment vendor information, etc.

1.1.1.2 Plant Walkdowns This lee 6 in paragraph will address the following points:

Walkdowns are needed to support the assurance that the PRA model reflects the plant's as-built, as-I operated condition and to supplement the information that can be gained reviewing documentaten of the plant.

Wetulowns nood to be conducted 10 contrm informsbon loomed from the above sources and to add delads, particulerty reisted to potengel operabng ermronments, apoliel considerations and equipment interactions, aconeettuilty issues, etc.

i The timing of the welkdowns is at the decreton of the analysts to suppo:t the PRA modehng process; but it is recommended that they be conducted during the early phases of the plant familientation process, and.then tht.teefter as required to. confirm questionnole information/ support additional intormation needs as they arise, or verify the understanding of plant changes for future revisions to the PRA.

1.1.1.2.1 Sequence / systems This section will highlight the fact that plant walkdowns need to verify equipment configurabons, spebel understandings,' accessibility, operating environments, equipment conditions, etc;;related to the proper modeling of the_ accident sequences, systems, and_ equipment.

1.1.1.2.2

- Human Reliability Analysis (HRA)

This section will highlight the fact that walkdowns (perhaps supported with plant simulaten informsbon and talkthroughs with operators) need to-verify those ergonomic and: human factors aspects'of operating equipment and monitonng pt st status to ensure proper modeling of human performance (pre, and post Initiator).

'.1.1.2.3 Containment This section will highlight the fact that walkdowns are needed to similarly verify those design aspects of containment to ensure proper modeling of containment in the PRA, including spatial details, m,manhility, equipment conditions, etc.

1.1.1.2.4 Intemal flood (unique considerations)

This section will highlight that walkdowns need to be used to verify or help identify sources barriers,= flood areas, propagation paths,- drains, existence of sump pumps, detection and isolation capabilities including

-C 'ri con:: ems, equipment heights and pwiecton features, etc. to accurately reflect the punt response to intamalflood events.

1-3 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Ev:.,nts, Full Pow:r, level 1 (Draft) 1.1.1 2 5 Internal fire (unique considerations)

This section will highhght that walkdowns need to verify or help identify sources, locations of transient and permanent combustibles, redundant equipment separation approaches and barriers, cable layouts, auto and manual detection equipment / indications / alarms, fire and hot gas propagation paths and barriers, auto and manual suppression design features and procedural capabilities including manual suppression training, identification of possible effects on equipment including actuation of suppression systems, etc.

1.1.2 Documentation Requirements This section will note that the specific documentation requirements of each PRA element are covered separately in the standardc However, this section will provide a generallist of docume/atation needs such as drawings, walkdown notes, enginemg calculations, etc. More specifically, this section will address the requirement to have a documentadon system that can serve three purposes:

Document the bases for the PRA, Document configuration control of the PRA including future revisions, and Document peer reviews of the PRA.

1.1.3 Application Requirements This section will note that the specific element application requirements are summarized in the following sections of this standard. However, as a generarization, the plant familiarization process must be sufficient to support the application. This will likely require a mix in the level of detail of information required; less data!!ed for those portions of the PRA not directly related to the application, more detailed for those aspects of the model affecting the application result.

1.1.4 Peer Revic,w Requirements This section will highlight the general principle that peer review of the PRA is required to deal with the uncertainties and lack of knowledge issues that arise. Peer review of the PRA relevant to the application must emphasize that the PRA cannot be just a Corporate level paper study if it is going to be used to support decisions about plant operation. How and whe'1 peer review is conducted is up to the ana!ysts butits goal must be to assure the PRA continues to represent the as-built, as-operated plant. Specific issues related to peer review of the PRA are addressed separately throughout this standard. Peer review is an important part of obtaining this assurance that the model reflects the plant, including a revir.w that the proper inputs to the PRA have been identified for use.

1.2 Initiating Event Analysis The objective of the initiating event analysts is to identify and group those events that present a challenge to normal plant operation. For this standard, an initiating event analysis is separated into five elements, regardless of whether a simple or detailed analysis is performed. The five elements are.

PRA Standard, Draft (STANDARD.RV3) 1-4

(

1. Intsmil Evants, Full Power, level 1 (Draft)

ModelSelection....

Definition of Initiator categories..

Selection of plant apecific initletors....

Screening out Initiators.,.. -..

Grouping initletors....

The requirements for each of these elements is dependent upon whether a simple or detailed analysis is performed. - Section 1.2.1 presents the requirements for performing a detailed initiating event analysis. For

- a simple initiating event analysis, some of the requirements listed in Section 1.2.1 can be relaxed. Section 1.2.3 provides a description of the requirements for a simple initiating event analysis. The requirements for documenting and peer reviewing the analysis is also dependent on the level of modeling. The differences in the documentation and peer review requirements are described in Sections 1.2.2 and 1.2.4, respectively.

1.2.1 Technical Analysis Requirements This section provides the requirements for each of the five elements used in this standard to describe a detailed initiating event analysis. Although an initiating events analysis can be separated into a different group!ag of elements, the requirements listed below are always applicable for a detailed analysis.

1.2.1.1 Plant Response Understanding This section will discuss the information sources necessary to identify and group initiabng event.-:' This_will include, plant-specific. sources such as LERs, scram reports, abnormal procedures,_FSAR Chapter;15 analyses, and load listings. Generic resources such as generic listings of initiabng events will_also be listed.

1.2.1.2 Model Selection Criteria This secton will docuss the methods that are acceptable for identifying initiating events.; These methods include engineering analyses (use of lists, review of LERs. etc) and master logic diagrams /: Do to the large experience bene in identifying initiating events in nuclear power plants,- engineering analyses are usually performed and the requirements listed are geared for that method ' _However, the identified requwements are portment for all methods of identifying initiating events.

1.2.1.3 Definition ofInitiators The objective of this element is to define the general categories of liitemal events that can potentially cause an upset of normal plant opersson and which results in a reactor trip or unplanned controlled shutdown. The intemal initiating event categories are:

Loss of coolant accidents transients intemal floods 1-5 PRA Standard, Draft (STANDARD.RV3)

1. Intern-J Evtnts, Full Pow:r, Lsv:11 (Draft) 0l.-

intamal fire 1.2.1.3.1 Loss-of-coolant accidents (LOCAs)

A detailed docussion will be provided S At a minimum, examples of events to be modeled include-primary system pipe breaks

+

e pressurtzed water reactor (PWR) steam generator tube ruptures (SGTRs) bollmg water reactor (SWR) foodwater pipe breaks '

+

s=

BWR eteem pipe breaks s

inadvertent opening of relief valves i

intertecin0 system looedcoolant accidents (18LOCAs) s reactor pressure veneel (RPV) rupture 1.2.1.3.2 Transients A detailed docueston will be providedc At a minimum, examples of events to be modeled include:

(.

automebc reactor shutdowns (scrams or trips) s unplanned controlled : reactors shutdowns -(including those caused - by _ degraded - equipment configurations) manual reactor trips or scrams

+

manual operator actions taken in anticipation of degrading plant condites

+

s transient-induced LOCAs.

loss of support systems

+

1.2.1.3.3 Internal Flood

- Intemal flooding events are included in an intemal events analysis.iThis section will refer to Section 1.9 for the requ6rements related to identifying, grouping, and screening of intomal flood initiators.

1.2.1.3.4 Internal Fire Intemal fire events are included in an intemal events analysisJThis sechon will refer to Sectxm 1.10 for the requirements related to identifying, grouping, and screening of intamal fire initiators.

1.2.1.4 Selection of Initiators The objective of this element is to identify the possible initiating events. This element encompasses a search of plant-specific and generic information sources. The requirements for both searches are provided below.

1.2.1.4.1 Plant-Specific Analysis A comprehensive plant-specific evaluation includes the following:

All general categories of events analyzed in Chapter 15 of the Final or Updated Safety Analysis PRA Standard, Draft (STANDARD.RV3) 1-6

1. Intsrnal Events, Full Power, Level 1 (Draft)

Report (SAR)(e g, increase or decreases in reactor coolant ficw), The Chapter 15 analysis includes both transients and LOCAs.

f Events resulting in a loss of pnmary core coolant. This ' icludes leaks and ruptures of various sizes and at different locations in the primary system (e.g., primary system pipe breaks, penetration failures, SGTRs and vessel rupture), in addition,' a systematic search of the reactor-coolant pressure boundary must be performed to identify any active component in systems interfacing with the primary system that could fail cr be operated in such a manner as to result in an uncontrolled loss of primary coolant (commonly referred to as ISLOCAs).

All actualinitiating events which have occurred at the plant. Actual plant scrams and unplanned shutdowns as documented in Licensee Event Reports (LERs) and scram reports must be included.

These initiators typically involve faults in the nuclear steam supply system (NSSS) and in the turbine-generator and related systems (referred to hereafter as the balance-of-plant). Plant modifications influencing occurrence rates must be considered.

All initiating events that have occurred at conditions other than full power operation (i.e during low power or shutdown conditions) are included unless it is determined that they are not applicable to full power operation.

All systems supporting the operation of other plant systems are reviewed to determine if their loss results in automatic scram, manual scram, or a controlled shutdown. Failure Modes and Effects Analysis (FMEA) are generally used to determine if an initiating event results from complete or partial failure of the system to operate, or from inadverteni operation of a syn in this method, the analyst determines for each component in the system: (1) its function, (2) the possible failure modes, (3) the fai'ure mechanisms, and (4) the effects of the failure on the system and the plant.

A system is evaluated if its loss would disrupt the normal operation of the plant. At a minimum, support systems that are examined include alternating current (AC) and direct current (DC) buses; cooling water or service water systems; instrument and service air; heating, ventilation, and air conditioning (HVAC) systems throughout the plant (including the control room); and instrumentation / control systems.

In determining whether the loss of a plant system or component must be treated as a support system initiating event, the expected level of degradation to nther plant systems (specifically, accident mitigating systems) is also determined and evaluated. This may require calculations to determine the resulting environment to which the mitigating equipment is exposed and comparison to equipment qualification information. (additional information will be provided)

Initiating events consisting of multiple equipment failures are included, if the equipment failures result from a common cause. For example, the failure of two DC electrical buses is included as an initiating event, if the failure is due to a common cause.

For multiple unit sites where systems are shared or can be cross-tied, initiating events that can impact both units must be identified in addition to those that will only impact a single unit.

1-7 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Eysnts, Full Pow:r, Level 1 (Draft)

An ISLOCA can be an important accident sequence because of its potentially significant contribution to the releases of radioactivity from the plant due to all possible accident scenarios. Therefore, the modeling of ISLOCAs and particularly the credit given for isolation of the ISLOCA, the predicted size of the ISLOCA, and the effects of the ISLOCA on other equipment can significantly affect the importance of this type of event. '(additionalinformation will be provided) 1.2.1.4.2 Genenc Analysis Allinitiating events considered in published PRAs (and related studies) of similar plants. NUREG/CR-4550 (Ref.1,1) contains a list of transient initiating events that have actually led to reactor trips and that must be considered.

(This section willinclude generic lists of typicalinitiating events.)

1.2.1.5 Screening Criteria Not every initiating event that causes a disruption of the plant has to be modeled. That is, accident sequences do not have to be developed for every initiating event. The objective of this element is to identify enteria for screening those events that do not contribute to core darrage or a large earty release. The following criteria can be used in the screening process:

The frequency of the initiating event is less than xxx per reactor-year (try) when the initiator does not involve either an ISLOCA, containment bypass, or vessel rupture.

The frequency of the initiating event is less than yyy/ry and the core damage could not occur unless at least two active trains of diverse mitigating systems are independently failed.

The resulting reactor trip is not an "immediate" occurrence. That is, the event does not require the plant to go to shutdown conditions until sufficient time has expired during which the initiating event conditions can, with a high degree of certairty (based on supporting calculations), be detected and corrected before normal plant operation would be curtailed (either administratively or automatically).

For example, a steam generator tube rupture event may have a retabvely low contribution to the total core damage frequency but may constitute a significant fraction of totallarge early releases. Initiating events such as these must not be excluded. The need to understand the potential consequences of an initiating event in order to exclude it from detailed analysis makes the process of excluding initiating events necessarily iterative.

As another illustration, the loss of switchgear room HVAC may not require the operator to initiate a manual shutdown for eight hours based on a room heatup calculation. Dunng this time, the operator can almost certainly detect and recover the fault using portable cooling equipment (as directed by procedures) anci prevent the need for a forced shutdown. In this case, assuming it can be shown that the operator can detect and venfy the cooling loss, loss of switchgear room cooling could justifiably be eliminated as an initiating event (if based on procedural guidance and calculational support).

The fact that an event has never occurred, by itself, is not a sufficient basis for eliminating an initiating event from evaluation.

PRA Standard, Draft (STANDARD.RV3) 18 l

1. Int rnal Events, Full Powsr, Level 1 (Draft) 1.2.1.6 Grouping Criteria Initiating events that result in the samc or nearly identical plant response often can be grouped to reduce the number of initiating events requM.4g further analysis. The objective of this element is to identify crNtia for grouping those initiating events with similar plaat respv.see The grouping of initiating events is based on the following:

I

. Initiating events resultiryi in the same accident progression (i e., requinng the same systems and operator actions for raitigation) can be grouped together. The success enteria for each system required for mitigation (e g., the required number of pump trains)is the same for allinitiators grouped together, in addition, all grosped initiators must have the same !mpact on the operability and performance of each mitigating system and the operator Consideration can also be given to those accioent progression attributes that could influence the subsequeist Level 2 analysis.

In conformance w,tn the criteria above, LOCAs can be grouped according to the size and location of the primary systee. breach However, primary breaches that bypass the containment must be treated separately.

Initiating events can be grouped with other initiating events with slightly different accident progression and success enteria if it can be shown that such treatment bounds the real core damage frequency and consequences that would result from the initiator. To avoid a distorted assessment of risk and to obtain valid insights, grouping of initiators with significantly different success criteria must be avoided. The grouping of initiators necessitates that the success criteria for the grouped initiators be the most stringent success enteria of all the individual events in the group. Low-frequency initiators not eliminated from consideration by screening can be grouped with other relatively high frequency initiators as long as such grouping does not distort the assessment of risk. If the potential for distortion exist, then the low frequency initiators must be considered separately.

1.2.2 Documentation Requirements The documentation of the initiating event task must be sufficient such that a peer reviewer can reproduce the results. At a minimum, the following information pertinent to initiating events must be documented:

A list or general description of the information sources that were used in the task.

Specific information/ records of events (plant specific, industry experience, " generic" data) used to identify the applicable initiating events, s

The initiating events considered including both the events retained for further examination and those that were ehminated, along with the supporting rationale.

Any quantitative or qual;tative evaluations or assumptions that were made in identifying, screening or grouping of the initiating events as well as the bases for any assumptions and their impact on the final results.

Documentahon of the FMEA performed to identify support system initiators and the expected effects 19 PRA Standard, Dn 1(STANDARD.RV3)

1. Internal Events, Full Pow:r, Loval 1 (Draft) on the plant (especially on mitigating systems).

Specific records of the grouping process including the success enteria for the final accident initiator

+

groups.

Documentation of findings of FMEA gor equivalent) performed on SSCs within the scope of the change but not modeled in the PRA,6 assess their impact on the scope and frequency of initiators.

1.2.3 Application Requirements The ' level of detail

• in performing tne technical analysis is necessarily needed for each element and requirement as desenbed above in Section 1.2.1; nor is the level of documentation the same for a simple model as listed in the above section for a detailed model. The level of rietail needed in the technical analysis and documentation for a simpie model versus a detailed model is listed below in Table 1.21.

Table 1.21. Summary of application requirements for initiating event analysis.

~

Element /

Technical Analysis for Simple Documentation for Simple Model Requirement Model To be completed b

1

(

1.2.4 Peer Review Requirements The requirements for performing the elements of an initiating event analysis are provided above in Section 1.2.1. A peer review is performed that ensures that the technical analysis performed meets the required PRA Standard, Draft (STANDARD.RV3) 1 10

1. Int:rnal Events, Full Powcr. Level 1 (Draft) standards. The necessary credentials of the peer reviewer are provided in Section 1.2.4.1. The enteria used in determining if each specific requirement was adequitely performed, whether for a simple or detailed model, is provided below in Section 1.2.4.2 1.2.4.1 Qualification of Peer Reviewers The qualifications of the peer reviewers for an initiating event analysis will be provided. The years of experience, type of experience, and knowledge of nuclear power plants will all be considered.

1.2.4.2 Review Criteria The entena used in determining if each specific requirement was adequately performed, whether for a simple or detailed model, is provided below in Table 12 2.

Table 1.2 2. Peer review requirements for an initiating event analysis.

Element /

Criteria for Review Required Credentials of equirement Simple Model Detailed Model To be completed 1.3 Success Criteria The objective of establishing the success criteria is to determine the necessary functions (through eventual identification of the minimum eystems and components needed) to prevent the onset of core damage for the identified initiators. Establishing success enteria is compnsed of two elements, regardless of whether a simple 1 11 PRA Standard, Draft (STANDARD.RV3)

1. Int:;rnal Evants, Full Pow r, Levsl 1 (Draft) or detailed analysis is performed. These elements include:

Defin/flon of core damage identifies the accident conditions under which a substantial amount of radiactive material may be released from the fuel.

Coro damage prevention identifies the safety fundions that will be challenged or which can be used to mitigate the initiating event (i e., are part of a strategy to prevent core damage).

The requirements for performing the technical analysis, documentation, and peer review are discussed below.

The level of detail may vary depending on whether a simple or detailed modelis required. These differences are differentiated and descr bed in Section 1.3.3.

1.3.1 Technical Analysis Requirements This section provides the requirements for each cf the elements that are needed for the success criteria.

1.3.1.1 Definition of Core Damage Accident sequence analysis establishes the success criteria which must be met to prevent core damage. The success enteria are thus dependent on the definition of core demage. Core damage has been defined in various ways, usually through peak cladding temperature limits or designated levels in the vessel. The onset of core damage generally means that no imminent recovery of sufficient coolant injection is anticipated, and therefore, a substantial amount (equivalent to or greater than the design basis) of the radioactive material contained in the gap between the cladding and the fuel is subsequently released. (This discussion will be expanded to describe what definition is to be used in a realistic,.detalled PRA.1The d6scussion.wlli also emphasse thJt the definition muct be supported by analysis, and that the definition is consistent for both Level 1 and Level 2 analysis) 1.3.1.2 Core Damage Prevention j

The objective of this element is to determine those systems and components necessary to prevent the onset I

of core damage. This element includes the fo: lowing major requirements:

Safety function identification Definition of functional success criteria Identification of function and system relationship Determination of system success criteria 1.3.1.2.1 Safety function identification Safety functions are those physical functions which can interfere with the progression of a postulated accident sequence toward core damage. The accident sequence model must incorporate the necessary safety functions, with their corresponding systems and operator responses, to prevent the Onset of core damage.

Accident sequence models ccn also delineate the functions required to protect the cr..tainment and influence t

PRA Standard, Draft (STANDARD.RV3) 1-12

1. Internal Events, Full Power, Level 1 (Draft) the amount of radioactive material released?" The safety functions modeled include reactivity control, reactor coolant system (RCS) integnty, reactor coolant inventory control and beat removal, and containment overpressure protection (both early and late). (A i inited definition of these safety functions will be provided.)

The containment overpressure protection functions are listed in the Level i considerations because the containment condition can adversely impact the core heat removal and inventory control functions.

1.3.1.2.2 Definition of functional success criteria 4

(

l For each of the initiating events identified, the safety functions that will be challenged or which can be used to mitigate the initiating event (i e., are part of a strategy to prevent core damage) must be identified. Defining core damage prevention strategies, i e., the success cnteria, must be an sterative process, starting with best

)

judgments based on experience, knowledge of existing plant calculations, and knowledge of the plant PRA model and its effects on calculational difficulties. (This section will be expanded and a nere detailed desenpton of safety function requirements for different initiators and different stages of the mission time will be preved.)

1.3.1.2.3 Identification of function and system relationship in order to model safety functions in the event tree / fault tree PRA model, it is necessary to relate them to plant systems The appropriate plant systems become the " top" events in the event trees. First the success enteria for each of the functions required to prevent core damage must be established (e g., the RCS inventory control function can be expressed in terms of required flow rate). Once established, these high-level functioas are related to more detailed functions and then to specific plant systems and operator acSons. Both frontline and support systems are included. Therefore, the system and operator responses modeled in a PRA include those fronthne, support systems, and operator actions needed to successfully meet the modeled safety function success entena The minimum hardware for each identified systen p.f, the number of pump trains) and operator responses required to meet the functicn success criteria determine the success enteria for responding to each initiating event group Note that some systems can provide multiple safety functions and that some functions can be supphed by multiple systems. (Additional discussion with examples for illustration

(

will be provided.)

1.3.1.24 Determination of system succesu criteria if the plant systems can prevent core damage from occurring during the missior time, then the accident sequence is considered successfully terminated, (As noted above, a more detailed discussion on the relationship between success enteria and mission time will be provided in Section 1.3.1.2.2.) The success entena specify the minimum equipment needed, determine the effects of degraded systems performance, and define the time available for recovery N each attemative success path available to the operators. In general, the success criterion for a system changes with the initiating events and the preceding events in the event trees.

The requirements provided in this section do not address event trees where the end state goes past the onset of core damage. Functions required for establishing the containment performance and release of radioactive msterial are identified in the i.evel 2 Standard Further event tree modeling to estabhsh plant damage states is not addressed in this sec' ion.

1 13 PRA Standard, Draft (STANDARD.RV3) l J

Int:rnci Events, Full Power, Level 1 (Draft)

In practice the determination of success enteria is generally based on tests, thermal-hyoraulic analyses, other mechanistic analyses, and documented expert knowledge. Calculations performed dunng the design of the plant to address the design-basis accident form a usefulinitial source of information. In these calculations, the most pessimistic assumptiot s on plant parameters are made to bound the consequences of these accidents Bccause of their ready availability, these calculations can be used as first approximations for establishing success enterit At this stage, the enteria are generally conservative. Usually other analyses of the same or similar plants are also identified and considered. Emergency procedures and other relevant procedures also provide information relevant to the success enteria. This preexisting information wil not be adequate to determine the success entena and timing of all possible scenarios for several reasons.

Such cntena are likely to be be so pessimistic that they will adversely affect the PRA results, and additional analysis to improve those success enteria will have to be performed. The use of realistic success enteria is necessary to provide assurance that the importance of the quantified accident sequences is reflected as accurately as needed. The use of success enteria which are excessively limiting (such as the success enteria used in design basis assessments) may distort the PRA results. For example, the licensing basis may require two out of four emergency core cooling pumps when "best estimate" calculations show that only one out of four pumps is needed to prevent the onset of core damage.

Since

• realistic" success critena, rather than the licensing-bases criteria, are desireable, the evaluation does not stop with safety related systems when non-safety-related eouipment may be available to perform the needed function, thereby preventing the onset of core damage.

In determining " realistic" success enteria, particularly when tuch enteria are considerably different from the SAR design basis or is not even addressed in the SAR, additional supporting analyses (e g., thermal-hydraulic calculations) must be the basis for the success entena that is credited in the PRA Representative examples of cnteria often used in PRAs that differ considerably or are not addressed by the design basis criteria are (a) feed and bleed mode for PWR core cooling, (b) primary / secondary system depressurization and use of low pressure safety injection and/or condensate to the steam generators whenever high pressure safety injection and/or main and auxiliary feedwater are unavailable in PWRs, and (c) in case of BWRs, use of attemate injection systems (such as control rod drive fiow or firewater) under conditions when all other injection systems are unavailable. These represent conJitions that go well beyond the single failure considerations applied in the design basis and hence ed not have to be treated in the originallicensing basis for tha plant. While plant-specific calculations are preferred, non-plant-specific calculations (e g, use of "similar" plant analyses perhaps with modification) are acceptable provided appropriate justification is established. The computer codes used to calculate success entena (either plant-specific or for a similar plant) must contain sufficient modeling detail and must be venfied for the conditions that exist in the success enteria application. (Additional discussion of what is needed for sufficiency will be provided.)

For grouped initiators, the accident sequenca modeling must reflect the most stringent initiator. For example, the coolant injection requirements for LOCA mitiators (which usually involve a spectrum of break sizes) are based upon the upper end of the break spectrum For other functions, the requirements may have to be based upon a different initiator included in the group.

The success enteria for preventing core damage can be dependent on the accident progression and timing.

For example, for a BWR, the control rod drive (CRD) system may not provide sufficient flow for coolant injection at the beginning of a small LOCA: however, at four hours ints the accident (given coolant injection PRA Standard, Draft (STANDARD.RV3) 1 14

1. Internal Events, Full Powor, Level 1 (Draft) has been occumng), the coolant inventory requirements are reduced and CRD flow is adequate, in addition, the time required to align a system may influence what time frame it can be credited in (e g., firewater may not be credited early on in an accident (e g, a LOCA) since it could require connection of multiple fire hoses, insertion of spool pieces, or opening of remote valves.

1.J.2 Documentation Requirements (This Section to be written.)

1.3.3 Application Requirements The ' level of detail" in performing the technical analysis is not necessarily needed for each element and requirement as described above in Section 1.3.1, nor is the level of documentation the same for a simple model as IF.ted in the above section for a detailed model. The level of detail needed in the technical analysis and documentation for a simple model versus a detailed model is listed below in Table 1.3-1.

(to be completed later)

Table 1.31 Application Requirements Elementl Technical Analysis for Simple Documentation for Simple Model Requirement Model to be completed i

p.-

/

1.3.4 Peer Review Requirements The peer review should r: view the following:

1 15 PRA Standard, Draft (STANDARD.RV3) i

1. Internal Ev:nts, Full Pow:r, level 1 (Drtit)

The acceptance enteria for fuel failure conditions, reactor coolant system failure boundary condrtions, and containment failure pressure.

That success has been defined at the functional level for reactivity control, RCS inventory control, RCS integnty, core heat removal, long term heat removal, and containment conditions.

(to be completed later)

The requirements for performing the elements of a success criteria analysis are provided above in Section 1,3.1. A peer review is performed that ensures that the technical analysis performed meets the required standards 4 The enteria used in determining if each specific requirement was adequately performed, whether for a simple or detailed model, is provided below in Table 1.3-2.

In making this determination, the necessary credentials of the peer reviewer are also provided. (Which must include thermal / hydraulic experience along with the other needed disciplines.)

Table 1.3 2 Peer Review Element /

Criteria for Review Required credentials of Requirement Simple Model Detailed Model Peer Reviewer (s) to be completed 1.4 Accident Sequence Analysis The accident sequence analysis PRA-element is required to determine the different possible accident progressions (resulting in either the prevention of the onset of core damage or in the onset of core damage)

PRA Standard, Draft (STANDARD.RV3) 1 16

1. Internal Events, Full Power, Level 1 (Draft)

I*

that can occur for each initiator group. For this standarri, an accident sequence analysis is separated into three elements. The requirements for the accident sequence analysis is depend 1nt upon whether a simple or detailed analysis is performed. These three elements are:

Model select /on cr/terla ensure that the scenario development is based on actual plant response and that technical details associated with alternative PRA models are appropriately accounted for.

Definition of analysis boundarles specifies key parameters associated with each sequence to ensure that the PRA results are relevant to risk management activities and are developed to an appropriate depth.

Model construction criterla define the process for event sequence development and screening.

The elements involved in performing the technical analysis, documentation, and certification are discussed below. The level of detail may vary depending on whether a simple or detailed modelis required These differences for each technical analysis element are described in Section 1.4.4.

Differences in the documentation and peer review are described in Sections 1 A 2 and 1.4.3 respectively.

1.4.1 rechnical Ar.alysia Requirements This section enumerates the requirements for each of the three elements used in this standard to describe a PRA event sequence analysis. Although an event sequence analysis can be organized into a different task structure, although the division of modeling effort between event sequence analysis and systems analysis (Section 1.4) can be strikingly different, the elements listed below alwcys apply and must be accessible in the

}

PRA.

1,4.1.1 Model Selection Criteria The requirements of this element are discussed under two topics:

Familiarity with details of plant response Model type 1.4.1.1.1 Familiar ty with Details of Plant Response The modeling of an accident sequence necessitates that the response of the plant systems and the operator accurately reflect the system capabilities and interactions, procedural guidance, and the timing of the accident cequences. Therefore, the development of the accident sequence models must correctly incorporate the planned response to an initiator that exists in the plant emergency and abnormal operating procedures and

{

as practiced in simulator exercises, 1.4.1.1.2 Model Type This section will discuss the two most common PRA models-the linked fault tree approach (the 'small event tree' model) and the event tree with conditional split fractions (the *large event tree" model)-and their variatl0ns. It will give caveats and special requirements associated with each.

1 17 PRA Standard, Draft (STANDARD.RV3)

E

1. Int: mal Ev:nts. Full Power, Lcvel 1 (Draft) 1.4.1.2 Definition of Analysis Boundaries Event sequence analysis assumptions and interfaces with other PRA-elements must be defined and their bases explained. At least the following analysis bourvl? ties will be discussed.

1 l

1.4.1.2.1 End States The requirements for end state definitions (core damage or specific plant damage states) will be discussed.

1.4.1.2.2 Mission Times Both general, scenarlo-specific and failure mode-specific mission times will be discussed. Definition will include reactor / plant is at a stable-steady state.

1.4.1.2.3 Conditional Success Cnteria Re:quirements for tracking changes in success criteria along different event sequences or in case of specific combinations of failure events will be discussed.

1.4.1.2.4 Extent of Modeling Functional Redundancy Guidance for setting the extent of modeling functional redundenc'/ will be provkied along with caveats waming of higher level problems that can defeat anticipatad redundancy.

1.4.1.2.5 Connection of Sequence Events to Success Criteria and System Definitions To be provided.

1.4.1.3 Model Construction Criteria To be provided.

1.4.1.3.1 Definition and Ordering of Sequence Events The modeling of an accident sequence necessitates that the response of the plant systems and the operator accurately reflect the system capabil, ties and interactions, procedural guidance, and the timing of the accident sequences. Therefore, the development of the accident seque. ice models must correctly incorporate the planned response to an initiator that exists in the plant emergency and abnormal operating procedures and as practiced in simulator exercises. In fact, the procedural gtdance along with timing information obtained through thermal-hydraulic calculations serves as the guide in 71e actual development of the accident sequence models. Operator actions required to mitipate an accident sequence (e.g., manual initiation of systems or special actions such as controlling vessel level during an ATWS in a BWR) must be modeled (see Section 1.6). Therefore,' system models' are generally placed in chronological order; i e.,the order that the system function or operator action is expected to be challenged. Deviations from the chronological representation PRA Standard, Draft (STANDARD.RV3) 1 18 l

1 Int:rnal Events, Full Pow:r, Level 1 (Dran) of the,nrocedural guidar ce must be justified and well documenteri.

1.4.1.3.2 Definition of Event Sequences in developing the accident sequences, the accident progressio1(as represented by the logic structure of '5e model) must also account for dependencies and interfaces between and among the plant safety functions, systems, and operator actions needed for accident mitigation. Functional, phenomenological, and operational dependencies and interfaces must be considered. Special requirements for handling dependencies in the i

event tree voith conditional split fractions approach will be riiscussed.

2 Functional dependencies exist where the success of one function 1; dependent or otherwise affected by the success / failure of another function. There are two oo,,endencies that must be addressed. ihese dependencies include: (1) Interaction of the initiating group with mitigating systems and operator actions and (2) interaction among the mitigating systems and operator actions.

The interactions of the initiating event group with evailable mitigating systems and actions are accounted for eithe* in the accident sequencs model or at the system model lev?l. Both immediate effects (e g., loss of systems such as the power conversion system (PCS) following loss-of-offsite power) and delayed effects (e g., loss of a system due to a loss of HVAC) must be included. Delayed impacts can be subtle and require that botn harth environmental impacts (discussed in more detail below) and protective trip logic be considered. An example of protective tr@ logic concems is the occurrence of a steam leak detection trip signal resulting due to a high room tempersiture that could result from a loss of room cooling. The loss of room coc'ing may occur for various initiators including loss of offsite power, loss of a cooling water systems, or loss of the HVAC system liself.

The interactions among mitigating systems and operato' 9Ctions are also accounted for either in the accident sequence model or at the system modellevel. One type of interaction 5 the successful operation of a system precluding the need for a redundant system performing the same function. The second type of interaction is the 'silure of one system precluding the opeiation of another systeni. An example of these types of functional dependencies in both a BWR and PWR is the requirement for the success of primary system depressurization before low-pressure coolant injection can be utilized. Alternatively, vessel depressurization may cause loss of a system due to pump run-out inducing a subsequent pump tnp. Another common example of a functional dependency is that battery depletion during a station blackout precludes continued operation of steam-driven systems.

Phenomenological dependencies mnnifest themselves where the environmental conditions generated during an accident sequence influence the operabihty of systems and equipment. Phenomenologicalimpacts can include generation of harsh environments that result in protective trips of systems (e g., due to high pressures or temperatures),'oss of ECCS pump net positive suction head (NPSH) when containment heat removalis lost, clogging of pump strainers from debris generated during a LOCA, failure of components outside the containment following containment failure due to the resulting harsh environment, closure of safety relief valves (SRVc) in BWRs on high containment pressure, and coolant pipe breaks following containment failure.

Phenomenological impacts can also be indirect. For example, failure of containment heat removalin a BWR must cause the operator to depressurize the vessel per procedures to maintain suppression pool heat capacity limits. Such an action can result in loss of driving steam for systems such as HPCI and RCIC.

1 19 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Events, Full Power, Lev:11 (Draft)

Circumvention of some of these failure modes such as bypassing of protective tnps, switching suction sources for pumps, and arranging alternate room cooling can be credited either in the accident sequence modeling or system models of the action can be realistically accomplished considering available staffing, the available time to perform the action, and any harsh environment where the actions must be performed. Most of these phenomenological dependencies are identified on an individual systern basis os part of the systems analysis (see Section 1.5).

Operational dependencies that are hardwired or are configuration dependent are present for some systems or components. An example of an operational dependency is that the suppression pool cooling mode of a loop of residual heat removalis not available when the system is in ine low pressure coolant injection mode.

Consideration must also be given to sequences in which the nature of the accident changes. For example, an initial transient may become a LOCA event due to reactor coolant pump seal failure or a demanded and stuck open primary rehef valve. Proper modehng of this progression change accounts for any dependencies among events previously discussed. Transfers to other sequence models to reflect the change in the sequence must be made with due consideration given to any differences between the modeled initiators.

1.4.1.3.3 Screening and Grouping Cnteria Screening will be discussed as a trade-off between model complexity and conservatism. That is, the reason for simpbfication is to make models and calculations more tractable and easier to review and verrfy, Screening of event tree transfers can be performed but must follow the truncation considerations provided in Section 1.10 (sequence quantification) and must be reevaluated for each risk-informed regulatory application.

1.4.1.3.4 End State Assignment Cnteria End states are defined in Section 1.41.2.1. Rules for assignment of event tree sequences to end states must translate success entena and Level 2 PRA phenomenological concerns into system success / failure space.

This section will lay out rules for this assignment.

1.4,2 Documentation Requirements The following information concerning the accident sequence modeling must be reported:

A list or general descl ption of the information sources that were used in the task.

i i

The success criteria esti,5hshed for e ch initiating group including the bases for the enteria (i e., the system capacities required to tr'itigate the accident and the necessary components required to achieve these capacities).

The models used (including all sequences) for each initiating event group.

A description of the accident progression for each sequence or group of similar sequences (ie.,

descriptions of the sequence timing, applicable procedural guidance, expected environmental or PRA Standard, Draft (STANDARD.RV3) 1 20

1. Internal Events Full Power, Level 1 (Draft) phenomanologicalimpacts, dependencies between systems, and other pertinent information required to fully establish the sequence of events).

Any assumptions that were made in developing the accident sequences, as well as the bases for the assumptions and their impact on the final results.

Existing analyses or plant s scific calculations performed to arrive at success criteria and expected sequence phenomena including necessary timing considerations.

Sufficient system operation information (refer to the following section) to supped the modeled dependencies.

Input, calculations, etc. (particularly to justify equipment operability beyond its " normal" design parameters and for which credit has been taken).

1 A.3 Application Requirements The complete

• level of detail" in performing the technical analysis is not necessarily needed for each element and requirement as desenbed earlier in this section. Similarly, the level of documentation will not be the same for a simple model as it would be for that listed in the above section for a detailed model. The level of detail needed in the technical analysis ar.d documentation for a simple model versus a detailed model is listed below in Table Table Application Requirements Element /

Technical Analysis for Simple Documentation for Simple Model Requirement Model l

l l~

l l

i l

l 1 21 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Events, Full Pow:r, Lovsl 1 (Draft) 4 Tab 4 Application Requirements Element /

Technical Analysis for Simple Documentation for Simple Model Requirement Model 1.4.4 Peer Review Requiremonic The requirements for performing the elements of an event sequence analysis are provided above in Section 1.4.1. A peer review is performed that ensures that the technical analysis performed meets the required standarde. The enteria used in determining if each specific requirement was adequately performed, whether for a simple or detailed model, is provided below in Table '

in making this determination, the necessary credenti11s of the peer reviewer are also provided.

Table Peer Review Element /

Criteria for Review Required Credentials of equirement Peer Reviewer (s)

- Simple Model Detailed Model i

i i

i

\\

l i

1 i~

l I

i 1.5 Systems Analysis System availability or reliability during accidents is evaluated in the systems analysis portion of a PRA. The i

systems analycis identifies the different pathways that can cause a system to fail to perform it's needed (as opposed to its design) function. The needed system function can vary depending on the intended use of the PRA Standard, Draft (STANDARD.RV3) 1 22

,.e

1. Intern 31 Events, Full Power, level 1 (Craft) system (e-g, a service water system may be requiret to perform ats design function of cooling required loads or as an afternative means of providing coolant injection into the vessel). For the PRA to accurately represent the plant, the systems analysis must accurately represent the operability of individual components within the system, the functional relationships between the components, and the dependency of the components on other systems. The requirements for a systems analysis are documented according to the following six elements:

System understanding is essential to perform a systems analysis. Criteria are provided to guide i

j this effort.

i Model type selection criteria are provided to identify the type of model required for a system to support system unavailability evaluations or accident sequence quantification.

i '

1 Definition of boundary conditions of analysis include the system success criteria and the l

components and failure modes included in the system boundary. Cnteria are provided to identify the system components and associated failure modes that can preclude the system from performing its l

required function (s).

System dependencies andInterfaces identification criteria are also provided to identify required o

support systems and other dependencies needed for system operation.

Screening criteria are provided to eliminate unimportant support systems, componer.'s, and failure modes from the system model.

Integrated model construction criteria are provided to guide the integration of multiple syr. tem models into a PRA.

The requirements for each of these elements is dependent upon whether a simple or dethiled analysis is performed. Section 1.5.1 presents the requirements for performing a detailed system analysis. For a simple systems analysis, some of the requirements listed in Section 1.5.1 can be relaxed. Section 1.5 3 provides a description of the requirements for a simple systems analysis. The requirements for documenting the systems analysis are provided in Section 1.5.2. The requirements for a peer review of the systems analysis -

is also dependent on the level of system modeling. The differences in the peer review requirements are desenbed in Section 1.5.4.

1.5.1 Technical Analysis Requirements This section provides the requirements for each of the six elements used in this standard to describe a detailed systems analysis. Although a systems analysis can be separated into a different grouping of elements, the requirements listed below are always applicable for a detailed systems analysis. A workplan or procedure is required te P Sate how the systems analysis is actually performed at each plant.

1.5.1.1 System Understanding A detailed representation of the design, operation, and maintenance of each modeled system is esscotial and must be based on a thorough understanding o' the plant. Plant information sources are reviewed to obtain -

1 23 PRA Standard, Draft (STANDARD.RV3)

1. Int: mal Evsnts, Full Powsr, Level 1 (Draft) information on system components and boundaries, dependencies on support systems, instrumentation and control requltements, testing and maintenance requirements, operating limitations such as those imposed by technical specifications, and procedures for the operatio1 of the system during normal and abnormal I

conditions. The types of plant information sources reviewed are identified in Section 1.1 and include system drawings, procedures, and descriptions.

The plant information sources provide information on how the system is supposed to operate. This knowledge is supported by reviewing actual system operating experieneJ #hich establishes how the system actually functions. Required information sources are listed in Section 1.1 and include Ucensee Event Reports (LERs),

maintenance work requests, test reports, operator / control room logs, and other information source that provides actual system operating information. In addition, system walkdowns are also performed to confirm the design of the system as represented in the plant drawings. Th walkdowns are procedurally guided with checklists provided to establish information needed for the systems analysis. Thit 'nformation includes location of system components, the accessibi'ty of the components, and the presence of annunciators that would indicate harsh environments in areas containing critical system components (e g., room temperature annunciators). Finally, operator interviews and involvement of plant system engineers are also necessary to establish how the systems are actually operated. Information concerning actual operating practices (e.g,, how flow is controlled in a system), subtle system interactions such as those identified in Section 1.5.1.4.5, additional system information not present in plant resources are obtained in these interviews.

In summary, all pertinent information must be collected and reviewed to help ensure that the bystem model is constructed according to the requirements listed below and reflects the as-built and m operated 18' system.

A more detailed discussion on plant familiarization is provided in Section 1.1.

1.5.1.2 Model Type Selection Criteria There are different analytical techniques that can be used to perform or suppoit a systems analysis.

Examples include; reliability block diagrams and fault trees. Fault trees are the preferred method since they are deductive in nature and, if properly performed, can identify all potential failure modes of a system and thus can be used to calculate the unavailabi'ity cf the system. In the large event tree approach for PRA (i e., t.be use of event trees with conditional spht fractions), the support system event tree is equivalent to a large fault tree and is thus considered a systems analysis model. Because of the prevailing use of fault trees in systems analysis, the remaining discussion focuses on the requirements for constructing fault trees. However, the requirements listed in this section are also apphcable for other system analysis methods The basic concepts for constructing fault trees are described in "The Fault Tree Handbook" (Ref.1.2).

Detailed fault tree models are generally required in analyzing a system. However, a simphfied fault tree or

. the black box approach (treating the system as a basic event)is acceptable for some uses of a PRA. These uses include the identification of plar,t s ilnerabilities and estimation of the risk from plant operation. However, for other applications of PRA, the level of detail of the system models must be sufficient to examine the issue being evaluated. Simply stated, the system model must include components and failure modes being reviewed or considered in the application. For example, use of the PRA model to evaluate the importance of motor-operated valves (MOVs) must include the contribution from MOV failures in the system models. The 8As built and as-operated defines the actual operation and design conditions of the plant at the current time of the PRA.

PRA Standard, Draft (STANDARD.RV3) 1-24 9

1. Int 2rnal Events, Full Power, Level 1 (Draft) requirements for constructing a detailed fault tree are discussed in the remainder of this section. The requirements for simphfied system models are addressed in Section 1.5.3.

SimplJied fault trees can be utikzed for identifying vulnerabilities when the dominant system failures are known from past experience or analyses (such as the use of the screening criteria in Section 1.5.1.5). An example of where a simpkfied fault tree could be utihzed for identifying vulnerabikties is for the automatic depressunzation system (ADS) system in a BWR. Here, common-cause valve failure and an operator error to manually initiate the system have been shown to be the dominant failure modes for the ADS. Since this system is dependent on several support systems (DC power and instrument air) used by other systems, these support system interfaces would have to be modeled.

Accepted data vah.es con be used for highly redundant systems with no support system requiremer" An example of where a data value is permissible is the reactor protection system (i e., the failure to scram the reactor). In this case, the reactor protection system (RPS) failure modes are independent of other system failures.

• 5.1.3 Definition of Boundary ConditLns of Analysis The objective of this element is to define the actual boundary of the system that will be evaluated, that is, estabhsh which components are required for system operation and what are their associated potential failure modes and mechanisms. This element includes requirements to determine:

System Success Cnteria System and Component Boundaries Component Failure Modes 1.5.1.3.1 System Success Cntena The enteria defining realistic (as opposed to conservative) requirements for c system to accomplish its needed function must be determined The success criteria is converted to failure enteria for the syttem and used to guide fault tree development. The success enteria for a system is generally expressed in terms of system capacity and the number of components required to achieve that capacity. The required system capacity is based on actual engineering analyses (e g, experiments, tests, or thermal-hydraulic calculations). Note that in some cases, multiple models for the same system may be needed to address the different success criteria required to mitigate different accident sequences. In addition, the success criteria is often time-dependent.

Section 1.31.2.4 presents a det?" s discussion on these issues and the requirements for establishing system success criteria 1.5.1.32 System and Component Boundaries All equipment and components contained within the sydem whose failure would prevent system operability (as identi_fied in the system success criteria) are included in the system model. This includes both active components (e g., pumps, valves, and air compressors) and passive components (e g., piping, heat exchangers, and tanks) that can significantly impact the system operation (the process of screening ccmponents from the modelis discussed in Section 1.5.1.5). The boundaries of the system equipment and components must also be defined. These definitions must match the definitions used to establish the 1 25 PRA Standard, Draft (STANDARD.RV3)

1. Internal Events, Full Power, Level 1 (Draft) component failure data. For example, a control circuit for a pump does not have to be included in the system model if the pump failure data used in quantifying the system model includes control circuit failures (portions of a component control system that impacts more than one component must be modeled separately in order to account for the dependent failure mechanism)

Finally, the defined boundaries must reflect the dependencies (e g., shared components) and interfaces (e.g, support systems) between equipment and systems (discussed further in Section 1.5.1.4).

1.5.1.3.3

- Component Failure Modes All relevant and possible failure modes for each component must be considered. - However, some components and specific failure modes can be excluded from the modelif the screening criteria in Section 1.5.1.5 are met.

These failure modes include the following:

Hardware Faults Out-of-Service Unavailability Dependent Faults Operator Faults Hardware Faults Hardware faults are those physical breakdowns of the equipment such that a component cannot function as designed (e.g., pump shaft breaks). Component failure modes that must be included in a system model include failures of active components to change state (e g., pump failure to start or failure of a valve to open),

i failure of active components to operate (e g., failure of a pump to continue to run once it has started) for a required mission time, and rupture and plugging of both passive and active components (passive component failures can generally be screened). Hardware faults that occur prior to an accident situation or during the course of the accident mitigation must be identified and included in the system model unless they are screened accarding to the enteria in Section 1.5.1.5. For e,, ample, plugging is a component failure mode that can go undetected in a component not normally operating until the component is tested or required to operate and can also occur during the system operation for accident mitigation. An additional component failure mode that must be reviewed (but is usually screened) involves spurious faults such as those that can also cause valves to realign into an undesirable position.

Modoling repair of hardware faults is generally not recommended because of uncertainty in the success of such actions and since it usually has little impact on the results. However, repair for any component can be considered if the probability of repair is justified through an adequate recovery analysis. The criteria for such a recovery analysis are provided in Section 1.6.1.5.2.

Out of Service Unavailability in modeling the out-of-service unavailability, both planned and unplanned test and maintenance contributions are included The type of testing and maintenance modeled must be consistent with the actuai practices and history of the plant for removing equipment from service. For example, maintenance events are applied at PRA Standard. Draft (STANDARD.RV3) 1 26 i

l i

1. Internal Events, Full Powsr, level 1 (Draft) the train level when procedures require isolating the entire train for maintenance Component level maintenance events are applied when only specific components are removed from service. Testing is modeled when a component or system train is reconfigured from its required accident mitigating position (unless such failures can be screened according to the enteria in Section 1.51.5).

Solution of the PRA results in cut sets with n eintenance on more than one system or system train in violation of technical specifications, Since mainte'ance and plant operation is performed according to technical specifications illegal combinations of inaintenance events can be removed from the PRA results (see Section 1.10).

Dependent Faults Dependent faults involve both explicit relationships b? tween components and failure mechanisms which affect more than one component, and common cause failures. Explicit dependencies generally involve shared components and support system dependencies such as electrical power, cooling requirements, and actuation logic. These support system interfaces are discussed in Section 1.5.1.3. Common cause equipment failures are multiple failures that result from a single event or failure (e g., common man':facture fault or common maintenance error). Given the current state-of-the art of common cause failure analysis and the data available, only intra system common cause failures are generally modeled. However, inter system common cause failures must be considered when supported by generic or plant specific data, as exists in the case of the BWR HPCI-RCIC pumps.

How common cause events are included in the model may vary (e g., included in the system fault trees, added after initial cut set review of independent failure combinations), but the approach must demonstrate that quantitative'y important common cause combinations are not missed. Common cause faults should be considered for identical components that provide redundancy and for which data is available to suppcit the event quantification. Candidates for common cause failures include, at a minimum:

motor-operated valves motor driven pumps safety-relief valves air-operated valves e

solenoid-operated valves e

check valves e

diesel generators a

batteries a

inverters e

circuit breakers

- For cases where the PRA involves the evaluation of common cause failures among a component type not supported by data, data for the componeN type closest in design and simitanty can be used to perform the evaluation Elimination of common cause events must be consistent with those expectations provided in Section 1.8, accident sequence quantification (i.e., truncation of any common cause events would be based or, low cut set frequency arguments). Finally, in evaluating the human error probabilities, the analyst would also consider common causes and ircorporate performance shaping factors (PSFs) to account for dependencies (see Section 1.6).

1 27 PRA Standard, Draft (STANDARD.RV3)

.. l

1. Int', mal Events, Full Power, Levsl 1 (Drcft) l*

Operator Faults l

Certain types of human error events must also be included in the systems analysis. These events include, at a minimum, those human actions that cause the system or component to be inoperable when demanded.

These events (also referred to as pre-initiator human events) are analyzed as part of the human reliability analysis discussed in Section 1.6 and include miscalibration of instrumentation and failure to restore components to an operable state following test or maintenance. Human error events related to the operation of the system or component can be included in the systems analysis model. These human error events, referred to as post initiator human act ons, include both response actions (those human actions performed in direct response to the accidents as directed by procedures) and recovery actions (those human actions performed to recover a failed or unavailable system or component). Post-initiator human events are scenario dependent and thus are quantified based on accident scenario timing and conditions. Dependencies can exist between post initiator human errors in different system models. Requirements for accourding for these dependencies and the quantification of post initiator events are also discussed in Section 1.6.

1,6.1.4 System Dependencies and Interfaces identification Criteria The objective of this element is to identify all the different dependencies and interfaces with other components or systems that could potentially affect the ability of the system to operate. This element includes the following major requirements pertaining to:

System initiation, Actuation, and Operation System isolation, Trip, or Failure System Capability Shared Equipment Subtle interactions 1.5.1.4.1 System initiation, Actuation, and Operation Those systems that are required for initiation, actuation, and continued operation of the system must be 4

identified. Automatic actuation signals, which often initiate multiple components and systems, must be included in the system model. The presence of the conditions needed for automatic actuation (e g., low vessel wat e level) must also be included in the system model. For example, a condition required to initiate a system automatically may not exist in some accident sequences. Thus, failure of that portion of the automatic

' lation system has a probability of 1.0 for those accident sequences. Human response actions, directed ty procedures, that are required for component and system operation can also be included in the model or accounted for in the final quantification of accident sequences. These manual actions can also be modeled as backups for automatic actuation signals when guided by procedural actions. The requirements for incorporating human response actions into the PRA are provided in Section 1.6.

The support systems required for operation of the system for a required mission time must be included in the model. In addition to actuation logic. system operation often requires support systems for control of

- components, component motive power, and cooling of components. Typical support systems include AC and DC power, cooling water systems, room ventilation, and instrument air. Support systems can be screened according to the criteria presented in Section 1.5.1.5.1. The impact of support systems can be directly included in the system model (e g., through fault tree linking) or through the process of identifying and PRA Standard, Draft (STANDARD.RV3) 1-28

1. Int: mal Events, Full Power, Lcvel 1 (Draft) e quantifying support states (see Section 1.4).

1.5.1 4.2 System isolation, Trip, or Failure Those condi*

.,t can cause the system to isolate or trip and those conditions that once exceeded can cause the cys.

to fail must be identifed. At a minimum 'hese conditions include environmental conditions, fluid temperaturs ind pressure being processed, extemal. ater level status, water and air temperature, pressure, humidity, and radiation le/els. These conditions may arise when other systems fall to function.

Examples of required systems include HVAC, service / component cooling water, heat tracing on piping and tanks to prevent boron solution precipitation, instrumentation (pressure, temperature, level, etc.), and water transfer systems to maintain tank levels.

Examples of conditions that can isolate, trip, or fail a system or component include:

For BWRs, high pressure in the RPV will prevent opening of the low pressure injection system isolation valves.

A diesel generator will trip when the high Jacket water temperature set point is reached. This condition can occur when the supporting cooling water supply to the diesel generator is lost.

Loss of room ventilation in rooms containing steam pipy,g can result in high room temperatures that trip steam leak detection circuitry which isolates a turbine-driven pump.

Inadequate pump NPSH due to low suction source level or high temperatures, clogging of strainers, steam binding of auxiliary feedwater pumps, water spray or flooding effects, and harsh steam environments are a few example of conditions that can fait pumps.

Because of the attempted realistic nature of PRAs, there are many examples of where allowance is made for the operability c' equipment beyond its design basis. This credit is allowed to account for the design margins built-in to most equipment used in a nuclear power plant and hence to recognize that equipment may function in conditions that are beyond those accounted for in the de.

,,1 basis. Examples include operability of pumps under saturated water suction condrtions, steam relief valve operability even when the valve is operating under two-phase flow conditions, battery operability given all charging to the batteries has been lost, human performance under undesirable environment or radiation conditions, etc.

While crediting the potential for this operability supports the intent to provide a realistic analysis, such judgments of operability can often ' drive" the results of the analysis and significantly impact the dominant sequences and contributing equipment that most affect the core damage frequency estimated..ne PRA; therefore, such judgments must be supported. Test data, actuai plant experience, vendor information regarding experience of similar equipment in other applications, and technical analyses are examples of acceptable evidence. Without such evidence, it must be assumed that once the expected conditions in the scenario exceed the design basis limits for the equipment, the equipment fails with a probability of 1.0.

1.5.1.4.3 System Capability Those conditions that can cause the system, though operable, to not meet the desired function must be 1 29 PRA Standard, Draft (STANDARD.RV3)

1. Internal Events, Full Power Level 1 (Draft) considered in the system model. Examples of this nature include flow diversion and insufficient inventories j

of air, water or power (e g., battery depletion) to support continued operation of the system for the assumed j

mission time. Such degraded conditions are explicitly treeted in the modeling process using realistic l

03erability requirements (e g, flow requirementr.) t' M are suprorted with engineering analysis. For example, engineering analyses may indicate that suffic'en' air is available for a system's operation even though non.

safety related portions of the air system fails to,$olate as esigned. Similarly, load calculations may indicate

)

that failure to strip loads from a DC bus would stii, ye Je sufficient power from batteries to run a system for a required mission time. Section 1.3.1.2.4 establishes the requirements for determining system success criteria through engineering analysis. If engineering analyses are not available,it must be assumed once degraded conditions exist that the equipment / system fails with a probability of 1.0.

4

)

1.5.1.4.4 Shared Equipment t

As mentioned previously, a system model may include components and equipment that are shared among systems. Special consideration must be given to shared components and failure modes that would normally

]

be screened from a system rnodel. In essence, the criteria for screening a component or failure mode as outlined in Section 1.5.1.5 must be applied to the probability that all the systems sharing the component fail i

simultaneously. Thus, passive components not typically included in a system model, may have to be included j

when their failure impacts more than one system (e g, a common suction valve on a pipe feeding two separate systems).

l 1.5.1.4.5 Subtle Interactions f

Failure of components to properly function as a result of a " subtle" interaction caused by changes in the l

operating environment, by conditions directly related to specific plant design or operational features, etc.

should be reviewed for inclusion in the system model. The process to identify these subtle interactions is not well structured. However, there are various information sources in the open literature (e g., NUREG/CR-4550, Vol.1) that can be used for identifying these types of interactions. These documents need to be reviewed to l

determine (based on system design and operation)if the listed interactions are applicable. A few examples l

of these types of interactions are provided below in Table 1,51, i

l c

i l

l Table 1.51. Examples of system subtle interactionw.

['

Subtle Interaction Description l

~

l Air binding of cooling water systems A leak in an air compressor cooler can result in air i

entering the associated cooling water system leading to air binding of the cooling water pumps.

i-Discharge check valve failures for cross-A check valve sticking open in the discharge line of tied pumps an idle pump of a two-train cross-tied system can result in recirculation of flow from the operating pump back through the idle pump.

PRA Standard, Draft (STANDARD.RV3) 1 30

1. Internal Ev:nts, Full Power, Levcl 1 (Draft) e Locked door dependencies During a station blackout, the loss of power to secunty systems may result in the inability to open secunty doors thereby restricting accident response actions.

1.5.1.5 Screening Criteria The elements of a system analysis discussed above identify those component, failure modes, and support systems that can cause a system to fail to perform its required function. The objective of this element is to identify the criteria that allows some support system, components, and failure modes to be screened or excluded from the system model. For specific applications of the system model, screened support systems, components, and failure modes may have to be retained or added to the model to achievi the required goal.

This element includes the following:

Support System Screening Cnteria Component Screening Criteria Failure Mode Screening Criteria 1.5.1.5.1 Support System Screening Cnteria Some identified support systems may not be required for operability of a system during particular scenarios or a defined mission time. Engineering analyses (e g., tests or calculations) can be used to eliminate support systems. For example, a room ventilation system may not be required for maintaining system components cool if the maximum expected room temperature, based on realistic or bounding room heatup calculations, are below equipment qualification limits. Without such calculations, the support system must be assumed required for continued component operation.

i Procedural guidance may allow for recovery actions given a loss of a support system. Examples include opening doors upon loss of room ventilation and manual control of a valve upon loss of control or motive power. The existence of procedularized recovery actions can not be used as a basis for eliminating support systems. However, such recovery actions can be included in the model quantification. The requirements for modeling recovery actions is provided in Section 1.6.

1.5.1.5.2 Component Screening Cnteria There are 3,ystem components that may not contribute significantry to the reliability or availability of the system, and therefore, may be excluded from the system model. The following criteria is used to determine when a component may or may not be screened or excluded:

The total failure probability of the component (sum of all failure modes) is at least two orders of magnitude lower than the next highest failure probability of another component in the same system train [ preliminary criteria; will be reexamined later) and the component (to be screened / excluded) does not have any dependencies or interfaces with other components or systems.

l 1-31 PRA Standard, Draft (STANDARD.RV3)

1. Int:m:I Ev2nts, Full Pow:r, Levst 1 (Draft)

Diversion paths may be excluded if engineering analyses indicate that flow paths of a particular size

+

will not divert enough flow to prevent system function.

1.5.1.5.3 Failure Mode Screenin2 Criteria 4

There are component failure modes that may not contribute to the reliability or availabil'ty of the component, and therefore, may a exclueed from the system model. The following criteria is used to determine when a component failure mode map or may not be screened or excluded:

The probability of the failure mode is at least two orders of magnitude lower than the next highest failure probability of another failure mode of that component [ preliminary criteria; w611 be reexmined later) An example is the probability of spurious closure of an MOV compared to the probability of it falling to open.

Position faults for components (such as those that can occur during or following test and maintenance j

activities) can be excluded if the omponent receives an automatic signal to place it in its required state and no other position faults exists (e g., pulled breakers) that would preclude the component from receiving the signal.

1.5.1,6 Integrated Model Construction Criteria The objective of this element is to identify requirements for the actual system model construction consisting of; Event Naming Scheme Model Linking Mndularization Analysis Interface 1.5.1h.1 Event Naming Scheme Construction and solution of system fault trees is generally accomplished through existing computer software that requires the use of an event naming scheme. In order to obtain an accurale representation of the dependencies between systems (particularly in the modeling of shared components, common human error events, and common cause failures) in the system fault trees and correct quantification of basic events, an event naming scheme must be consistently applied.

1.5.1.6.2 Model Linking Many PRAs use the process of fault tree linking to determine system unavailabilities and accident sequence frequencies. Fault tree linking often results in circular logic that must be brcken before the model can be solved. The circular logic is usually related to linking multiple support system fault trees and can be different for different uses of the support systems (e g., use of an AC bus in powering a battery charger would result in different logic loops than when the bus is supporting a cooling water system that cools the diesel generator powering the bus). Breaking of the logic loops at incorrect locations can result in incorrect cut sets.

Furthermore, the use of a linked fault tree generated for one configuration for a different configuration also can PRA Standard, Draft (STANDARD.RV3) 1 32

1. Internal Events, Full Power, t.ovel 1 (Draft) result in incorrect cut sett. Thus, circular logic m4 he broken at the location in the knked fault tree where l

it occurs (i e, t.Jt nigher in the fault tree) mnd different linked models must generated for each required system configuration. Guidance for breaking logic loops is provided in the " Interim Reliabikty Evaluation Program Procedures Guide," NUREG/CR 2728.

Similarly, correct use of the support state approach also requires that assignment of support states properly accounts for support system dependencies on other support systems For example, an accident sequence involving loss of offsite power, operation of an emergency diesel generato 9d fanure of the associated diesel generator coohng water system must be assigned to a support state invowing loss of the diesel generator.

1.5.1.6.3 Modularization if supercomponents or modules are used to simplify system fault trees, the modularization process must ' e o

performed in a manner that avoids grouping events with different recovery potential. The following types of events can not be included in a module:

hardware failures that cannot be recovered versus actuation signals which can, human error events that must be analyzed within the context of different accident sequences, events which are mutually exclusive of other events not in the module, e

events which occur in other fault trees (especially ccmmon cause events), and e

support systems used by other systems.

1.5.1.6.4 Analysis interface The quantification of the component failure events in the system model must utihze plant specific data where it exists (see Section 1.7) and human error probabilities must also be based on plant-specific factors (see Section 1.6). The quantification must also corr 3ctly reflect whether the system components are normally operating or in standby. The unavailabikty of standby components must include faults that go undetected between tests. Demand failure probabihties must reflect the actual number of demands expected of the component dunng the mitigation of the accident. The mission time used to quantify component reliabikty must be sufficient to ensure a stable plant configuration (i e., at least hot shutdown) has been achieved.

1.5.2 Documentation Requirements The type of information required to document a systems analysis is the same for a detailed and simple system analysis. However, the amount of information included in the documentation may be different but must be sufficient to confirm the accuracy of the model. The minimum requirements for documenting a systems analysis are:

A workplan or procedure dehneating how the systems analysis was performed.

A list or general description of the information that was used in the development of the system models, including a brief discussion of the following:

System function and operation under normal and emergency operations 1-33 PRA Standard, Draft (STANDARD.RV3) l

1. Internal Events, Full Pow 2r, Levst 1 (Draft)

Actual operational history indicating any past problems in the system operation System success criteria and relationship to accident sequence models Human actions necessary for operation of system List of all test and maintenance procedures System schematic illustrating all equipment and components necessary for system operation Completed checklists from walkdowns Notes from discussions with plant staff System dependencies and shared component interfaces documented using a dependency matrix or dependency diagram indicating all dependencies for all components among all systems (frontline and support)

Table listing failure modes modeled for each component and event quantification General spatial information and layout drawings to support external event analyses Assumptions or simplifications made i,1 development of specific system models.

The nomenclature for the basic events modeled.

The freeze date used to represent the design and operation of the plant.

Any general assumptions that were made in the development of the systems models, as well as the bases for the assumptions and their impact on the final results.

List of all components and failure modes included in the model, along with justification for any exclusion of components and failure modes.

Information and calculations to support equipment operability considerations and assumptions.

References to specific controlled input documents used for modeling (e g., piping and instrumentation diagrams).

Documentation of modularization process (if used).

Records of resolution of logic loops developed durir 3 fault tree linking (if used).

1.5.3 Application Requirements Not every system analysis needs to be performed to the same ' level of detail.* A fault tree can be simplified in some situatens to include only the dominant types of failures. In addition, a single data value can be used to represent system unavailability for systems where sufficient experience exists. Care should be taken to

- model those aspects of the system which forrn dependencies with other systems so that dependent or comrnon cause events are properly handled.

- The differences between the requirements for a simple system analysis versus a detailed analysis are listed below in Table 1.5-2.

PRA Standard, Draft (STANDARD.RV3) 1 34

)

e

1. Internal Evsnts, Full Powcr Level 1 (Draft)

Table 1.5 2. Summary of requirements of Simple Versus Detailed Systems Analysis.

Element / Requirement Technical Analysis for a Simple Model System Model Type System comprehension Model type System Boundaries System success enteria System and component boundaries Component failure modes System Dependencies and interfaces System initiation, actuation, and operation System isolation, tnp, or failure System capability Shared equipment Subtle interactions Screening Criteria Screen l exclude support systems Screen / exclude components Screen / exclude failure modes Model Construction Event naming scheme Modellinking Modularization Quantification 1 35 PRA Standard, Draft (STANDARD.RV3)

1. Int:rn:l Ev:nts, Full Power, Lev:11 (Draft) 1.5.4 Peer Review Requirements The requirements for performing the elements of a system analysis are provided above in Section 1.5.1. A comprehensive peer review is performed that ensures that the technical analysis performed meets the required standards. The necessarf credentials of the peer reviewer are provided in Section 1.5.4.1. The enteria used in determining if each specife requirement was adequately performed, whether for a simple or detailed model, is provided below in Section 1.5.4.2.

1.5.4.1 Qualification of Peer Reviewers The peer review team for the systems analysis should have previous experience in PRA including, at a minimum, systems and data analysis. Systems -nalyst(s) are required to review the fault tree content and construction and data analyst (s) are required to check the continuity of the component boundaries with the data used in quantifying the model. Team experience in HRA (to review modeling of human actions), accident sequence analysis (to review the interface of the system models with the accident sequence mod,..s), and thermal-hydraulic analysis (for success criteria evaluation) is also desirable but can be included in the peer review teams for those elements of the PRA (i.e., those portions of the systems analysis can be reviewed under those tasks). The team should have specific systems analysis experience on the types of systems being reviewed. Preferably, at least one member should have direct knowledge of the plant being reviewed.

The number of peer reviewers required can be determined by the capability of selected reviewers to meet the above team criteria. However, each peer reviewer for the systems analysis task must have at least 5 years direct experience in performing the PRA task they represent on the team. For example, personnel selected to review the fault trees must have at least 5 years experience in gathering information required for a systems analysis and actually constructing, linking, and quantifying fault trees and personnel assigned to the team to review the continuity between the component boundaries and the data and must have 5 years in performing plant-specific dMa analysis. In general, the peer reviewers must demonstrate a knowledge of the requirements identified in Section 1.5.1 for a detailed systems analysis.

1.5.4.2 Review Requirements E

A comprehensive and detailed peer review is required to er,Nre the adequacy of the system models. To accomplish this objective, the following criteria must be met by the team:

. Familiarization with system design and operahon by the peer review team. [ expand M ttxplain what is meant by familiarization, to what extent does the peer review team need to become familiar, do they need to look at every plant source and perform walkdowns? what is acceptable, provide criteria for A

familiarization)

. Confirmation that the general procedure or workplan used to perform the system analysis incorporatated the requirements listed in this standard for each element. (expand text to clarify what is meant by this criterla]

PRA Standard, Draft (STANDARD.RV3) 1 36

a

1. Internal Events, Full Power, Level 1 (Draft)

Depending on the degree to which the workplan incorporated the requirements, check that the requirements for each element were adequately performed. The enteria for determining whether each element was adequately performed is provide below in Table

[ add words to explain what is acceptable in determining that something is adequately performed) If the workplan included all the requirements Irted in the standard, checking every system is not r64uired; checkirg selected systems is acceptable. [ provide criteria in determining which systerr. to look at, e.g., must look at least 3 systems that include an NSSS, support system, different analyst....] If the workplan did not include all the requirements listed in fue standard, then chechng every system may be needed. Criteria for detemining which systems need to be reviewed can be element dependent and is listed below in Table

. the criteria to be presanted in the table will build upon the BWROG Certification Guidelines]

Table 1.5-3. Peer review requirements for a system analysis, i====:n Eiementi Criteria for Review 9 " * * '"

Detailed Model Simple Model System Model Type System For each element, criteria to be written comprehension covering:

(1) which systems need to be reviewed (2) what to review in determining technicaladequacy Model type System Boundaries System success criteria System and component boundaries Component failure modes System Dependencies and Interfaces System initiation.

actuation, and operation System isolation, trip, or failure System capability 1-37 PRA Standard, Draft (STANDARD.RV3)

1. Internal Events, Full Pow:,r, Levd,1 (Draft)

Table 1.5 3. Deer review requirements for a system analysis.

Element /

Criteria for Review 9 **"

Detailed Model Simple Model Shared equipment Subtle j

interactions Screening Criteria Screen / exclude support systems Screen / exclude components Screen / exclude failure modes Model Construction Event naming scheme Modellinkinc Modularization p Quantification 1.6 Human Reliability Analysis (HP.A)

The objective of the HRA is to identify and evaluate those human actions that play a role in causing, preventing and mitigating core damage. An HRA is comprised of seven basic elements, regardless of whether a simple or detailed analysis is performed. These seven elements include:

Definition of Human hctions

• Identification and Selection of Pre-Initiator Human Actions

-ving of Pre-Initiator Human Actions

• E

• Jation and Quantification of Pre-Initiator Human Actions PRA Standard, Draft (STANDARD.RV3) 1-38

1. Intimal Ev:nts, Full Pow:r, Level 1 (Draft)

> Identification and Selection of Post Initiator Human Actions Screening of Response Related Human Actions Evaluation and Quantification of Post Initiator Human Actions The requirements for performing the technical analysis, documentation, and peer review are discussed below.

The level of detail may vary depending on whether a simple or detailed model is required. These differences are differentiated and described in Section 1.6.3.

1.6.1 Technical Analysis Requirements This section provides the requirements for each of the seven elements that are needed for the HRA.

1.6.1.1 Definition of Human Actions The objective of this element is to define the human achons to be modeled in the PRA. This elenwnt includes the following requirements:

. Pre-Initiator Human Actions

. Post-Initiator Human Actions 1.6.1.1.1 Pre Initiator Human Actions Pre-initiator human actions are those actions that can cause a system or component to be unavailable when demanded (referred to as pre-initiators).

1.6.1.1.2 Post-Initiator Human Actions Post-initiator human actions are those human actions needed to prevent or mitigate core damage given the initiator has occurred (referred to a0 post-initiators).

1.6.1.2 Identification and Selection of Pre-Initiator Human Actions The objective of this element is to identify and select the pre-initiator human actions that will be modeled in the PRA. This element incudes the following requirements:

. Maintenance Related Human Actions

. Test Related Human Actions

. Calibration Human Actions Pre-initiator human actions that could result in an unrevealed unavailability of a standby system or component must be modeled At a minimum, the human actions to be modeled include restoration errors in ietuming the system and components to their normal state after completion of testing and maintenance, and miscalibration arrors of critical instrumentation (both independent errors and common-cause miscalibration where s-appropriate).

1-39 PRA Standard. Draft (STANDARD.RV3)

1. Intsmil Events, Fu;l Pow:r, Levsl 1 (Draft) 1.6.1.2.1 Test Related Human Actions Toot related human schons r adeled include failures to restore equipment to correct standby status as a result of carrying out tests in which the equipment required to respond to an initiating event is realigned away from its required position, and for whict' the demand signal is bypassed or defeated (e g., testing of SLC system in BWRs), (Additional information will be provided here.)

1.6.1.2.2 Maintenance Related Human Actions Maintenance related human actions modeled it. lude failures to realign those components (typically valves) which, for the execution of maintenance acts, are required to be realigned away from their nonnal positions, and are either manually operated, or power operated with power removed or automatic realignment disabled (Additional int tmation will be provided here.)

1.6.1.2.3 Calibration Related Human Actions Calibration related human actions modeled include miscalibrations of instrumentatio" which could cause failure of a required system to initiate or ;ealign, e g., steam generator level sensors. (Additional information will be provided here.)

1.6.1.3 Screening of Pre-Initiator Human Actions a

The objective of this element is to describe the criteria to be included in screening pre-initiator human actions from further analysis.This element is comprised of the following requirements:

. Qualitative Criteria

. Quantitative Criteria There are numerous human actions that do not play a " critical" role in initiating, preventing, or mitigating core damage. A screening analysis can be performed to identify and exclude these = 'ents from detailed evaluation.

Human actions, such as all pre-initiators, generally cannot be excluded from evaluation based on the argument that these events are included in the component hardware data. Many human actions (such as miscalibration) occur rarely and are not necessarily tellected in the random failure data. Further, their effects can be subtie in that they impact multiple systems and thus can play a key factor in contributing to core damage.

1.6.1.3.1 Qualitative Pre-Initiator Human Action Screening Qualitative criteria for screening pre-initiator human actions includ3 the following:

. If the components that are reconfigured are misaligned but not disabled and would receive a realignment signal on system demand, then the eveats associated with realignment of the compc9nts can be screened out. (This is already emisedded in the selection criteria suggested above.)

PRA Standard, Draft (STANDARD.RV3) 1-40

1. Intsrnal Events, Full Power, level 1 (Draft)

. If the activity is a maintenance activity and a full functional test is carried out on completiori of maintenance, then misalignment of components can be screened out.

. If the Status of reconfigured components is indicated in the control room, and the expected frequency of reconfiguration is low, compared to the frequency of status checking, the failure to restore can be screened out.

1.6.1.3.2 Quantitative Pre-Initiator Human Failure Event Screening Quantitative screening of pre-initletor human actione must meet the following criterion:

. Quantitative screening values for post-initiator human actions are typically used in the initial PRA quantification process when the human actions are modeled in the event trees as top events or in the fault trees. The screening values assigned must be high enough to ensure that the impact of dependencies between events are not underestimated. If screening values are too low and potential dependencies are not considered, importan: sequences may be truncated. If screening values are assigned before the initial quantification without 11y examination of the events and potential dependencies, screening values not less than 0.5 (assuming that cutset trui1 cation values around 1E-9/ry are used in the quantification process) are recommended for post-initiator human actions.

1.6.1.4 Evaluation and Quantification of Pre-Initiator Human actions The objective of this element is to describe the criteria for evaluating and quantifying pre-initiator human actions. This element is comprised of the following requirements:

. Activity Comprehension

. Dependencies and interfaces

• Recovery Criteria 1.6.1.4.1 Activity Comprehension Evaluation and quantifcation of pre-initiator human actions must include the following activities concemed with plant characteristics and practices:

. system comprehension,

. procedure comprehension, plant practices, e

walkdowns, and interviews.

(Descriptions of the above activities will be provided.)

1.6.1.4.2 Dependencies and Interfaces Dependencies and interfaces between pre-initiator human actions and their relationship to the accident 1-41 PRA Standard, Draft (STANDARD.RV3)

I

1. Int:;rnal Events, Full Powtr, Level 1 (Draft) scenario including the following:

. The capability of the operator to impact more than one component, train, or system is considered. (For example, the likelihood of the operator miscalibrating all level and pressure instrumentation simultaneously must be considered.)

The following criteria can be used to help ensure that no dependencies exists between human actions (i e.,

the events are truly independent):

. No common " environmental" factors exists (lighting, temperature, etc.)

. No common human-related factors exists (e g., same/similar procedure, common-cues, same crew performing multiple calibrations on the same day, etc.)

(Additional discussion to be provided) 1.6.1.4.3 Recovery Cnteria (D6scussion to be provided)

= 1.6.1.5 Identification and Selection of Post-Initiator Human Actions The objective of this element is to identify and select the post initiator human actions that will be modeled in the PRA. This element includes the following requirements:

Response Related Human Actions Recovery Related Human Actions 1.6.1.5.1 Response Related Human Actions Response actions inc!ude those human actions performed in direct response to the accident (i.e., actions delineated by the emergency operating procedures). Human response actions included are those actions required to manually initiate, operate, control, or terminate those system and components needed to prevent or mitigate core damage. The modeled response actions include those actions needed to ensure that the systems or components nieet the requirements of the success criteria defined for those systems or components in the systems analysis.

1.6.1.5.2 Recovery Related Human Actions Recovery actions include those human actions performed in recovering a failed or unavailable system or component. Recovery actions may also include us'ng systems in relatively unusual ways. However, credit for recovery actions may not be given unless at leart some procedural guidance is provided or operators receive frequent training that would lead them to perform the required actions. Recovery actions can also include rest 3(ation and repair of failed equipn,3nt (i.e., hardware failure). Generally, restoration and repair of (LOOP), ioss of PCS, loss of diesel generators, and loss of DC buses have been credited. These are usually treated by using actuarial data rather than by HRA methods. Table 8.2-10 of NUREG/CR-4550, PRA Standard, Draft (STANDARD.RV3) 1-42

1. Internal Events, Full Power, Level 1 (Draft)

Volume 1 (Ref.1.3) provides accepicble values for these events. NSAC 188 (Ref. X.9) or a later NSAC report such as NSAC-194 is also an acceptable source of data for restoration of offsite power. Due to the generallack of acceptable data, restoration and repair of other equipment is generally not credited.

1.6.1.6 Screening of Response Related Human Actions The objective of this element is to describe the criteria to be included in screening post-initiator human actions from further analysis. This element is comprised of the following requirements:

• Qualitative Criteria

• Quantitative Cnteria

{

There are numerous human actions that do not play a "cntical" role in initiating, preventing, or mitigating core t

damage. A screening analysis can be performed to identify and exclude these events from detailed k+

evaluation.

1.61.6.1 Qualitative Response Related Human Action Screening (Discussion to be provided) 1.6.1.6.2 Quant;tative Response Related Human Action Screening Quantitative screening of post-initiator human actions must meet the following criterion:

• Quantitative screening values for post initiator human errors are typically used in the initial PRA quantification process when the human actions are modeled in the event trees as top events or in the fault trees. The screening values assigned must be high enough to ensure that the impact of dependencies between events are not underestimated. If screening values es too low and potential dependencies are hot considered. important sequences may be truncated. If screening values are assigned before the initial quantification without any examination of the events and pot;ntial deoendencies, screening values not less than 0.5 (assuming that cutset truncation values around 1E-9/ry are used in the quantification process) are f

recommended for post-initiator Human actions (Additional discussion to be provided.)

1.6.1.7 Evaluation and Quantificattor of Post-Initiator Human Actions The objective of this element is to describe the criteria for evaluating and quantifying post-initiator human actions. This element is comprised of the following requirements:

• Sequence and Activity Comorehension

. Human Errors Mode'ed

. Dependencies and Interfaces

. Inte; ation 1.6.1. 7.1 Sequence and Activity Comprehension 1-43 PRA Standard, Draft (STANDARD.RV3)

1. Int:rnal Events, Full Power, Level 1 (Draft)

The actual performance of the operators is reviected in the estimated likelihood of an operator failing to d.agnose, perform, or properly execute the needed action. Therefore, the quantification of the human actons incorporates plant-specific factors and pract ~' t These factors include the following:

• The human actions selected ior evaluation must reflect the actual operating and maintenance practices of the plant. At a mininium, plant walk-throughs, inte: Views with plant personnel (e g., training, maintenance, operators, shift supervisor, shift technical advisors), and procedure review are performed in identifying and selecting the human actions. Observation of simulator exercises of the modeled accident sequences can be used to provide additional information regarding control room operational practices and crew performance. Similarly, observations of maintenance crew performance can also be made.

. Plant " condition " affecting operator performance and human performance shaping factors including:

The quality (type and frequency of training) of the operator training, the wntten procedures and of the adm.nistrative controls.

- The environment (e g., hghting, heat, radiation) under which the operator is working.

The accessibility of the equipment reciuinng manipulation.

- The necessity, adequacy, and availability of special tools, parts, clothing, etc.

- The quality of the human-rrachine interface.

- The availability of instrumentation needed to take corrective actions.

i

. The time available to the operator to determine ano perform the desired action, compared with time that is actually needed to determine and perform the action. The available time is accident sequence specific and determined from engineering analysis which include actual time measurements derived from walk-throughs and simulator observation. The point at which the operators receive relevant indicators is also considered in determining available time. Thermal-hydraulic calculations can be used to help determine

(

the time available for performing required actions.

. Task characteristics such as the number of subtasks and their complexity.

. The potential for additional checks (e g, due to indication of changing plant parameters) on operator actions (immediate recoveries) and the expected arrival of additional support such as an emergency response team.

(Additional discussion will be added to this section) 1.6.1.7.2 Human A.ction Types The HRA must address both the " diagnosis" and " execution" portion of each post-initiator human action.

Diagnosis is usually assumed to include detect:ng and evaluating a changed cr changing condition and then deciding what response is required. Obviously, the complexity can vary, but a diagnosis may entail no more than detecting en ind: cation in the control room and deciding to execute a prescribed response according to symptom-based emergency operating procedures (EOPs). Evaluation of the execution of a human action entails examining the activities to be conducted as indicated by the diagnosis.

Post-initiator human actions are assumed to entail a diagnosis phase. Exceptions to evaluating a diagnosis PRA Standard. Draft (STANDARD.RV3) 1-44

1. Interncl Events, Full Power, Level 1 (Draft) phase include those instances when the diagnosis of a previously modeled human event can be shown to include that for a subsequent event. (Additional discussion will be added.)

Failure to explicitly model and evaluate the execution of a human action is appropriate when the HRA method being used stipulates that the likelihood of potential execution failures is included in the diagnosis value for certain kinds of events. However, relatively complex actions may not be contained within the diagnosis value (e g., unusual actions performed outside the control room). The application of any HRA method requires the analyst to ensure that the assumptions and characteristics of the method are appropriate for the event being analyzed. Most existing methods provide alternatives for treatment of different types of events.

1.6.1.7.3 Dependencies and Interfaces Dependencies and interfaces between the post-initiator human actions and their relationship to the accident scenario including the following:

. For post-initiators, the human event is evaluated relative to the specific context of the accident progression.

Therefore, for different accident sequences, the human event is evaluated for each sequence. The influence of previous human actions and system performance are considered relative to their influence on the human event under consideration. Time dependency is also considered in the sense that the total available time must be considered across the entire sequence. For example, if most the total time available is allocated to the first operator action in a sequence, then the potential success of remaining actions is impacted.

The following criteria can be used to help ensure that no dependencies exists between human actions (i.e.,

the events are truly independent):

No common environmental" factors exists (lighting, temperature, etc.)

No common human-related factors exists (e g, same/similar procedure, common-cues, same crew performing multiple activities on the same day, etc.)

Different personnel are involved in diagnosing and executing the human action or series of human actions.

Operators can perform numerous activities during an accideat to prev nt core damage from occurrinr However, the likelihood of these actions can become questionable if too many or unrealistic operator actions are modeled. While all reasonable actions for which time is available can be modeled, it is recognized that an operator or control room failure in one instance (e g., failure to follow procedure) has the potential to influence the likelihood of later operator success. Thus, potential dependencies must be considered and it is recommended that for a given cutset, the total" crew" (both control room and ex-control room operators plus any and all other personnel such as the emergency response team) failure probacility be bounded to reflact resource limitaticns and other uncertain factors.

(Additional discussion to be provided.)

1.6.1.7.4 Integration 1-45 PRA Standard, Draft (STANDARD.RV3)

i.

l 1.- Int: mil Events, Full Powsr, level 1 (Draft) 9 (Note. The secbon below will probably be reorganized and additional discussion added.)

Errors made in performance by the original operator can be " recovered" by the same operator (e.g., new plant status information) and by other plant personnel (e g., post maintenance verification by a separate operator, role of shift technical advisor, role of emergency response team). Total credit for all such " recoveries" must not exceed a factor of 10 (higher credits must be identified and justified). This suggested limit is based on the uncertainty associated with determining the actualindependence of the plant personnel and the ability to precisely quantify human performance, particularly considering all the different uncertainties.

The above factors are used in determining what data are selected from the various HRA methods in deriving the actual human error probabilities (HEPs). The quantified HEPs are characterized as dictated in the selected HRA method For example, the Technique for Human Error Rate Prediction (THERP) characterizes data as median values with a log normal distribution. However, the values input into the sequence quantification must be mean values; therefore, depending on the HRA method being used, conversion to a mean might be necessary. Furthermore, the associated distribution can potentially result in a portion of it being greater than 1.0 (e g., HEP mean value of 0 8 with an erTor factor of 15 will result in the 95% confidence limit being greater than 1.0). In such cases, modification of the distribution is required. An acceptable approach is the use of the maximum entropy distribution which sets both the upper and lower limits.

- An essential aspect in the quantification of the Human actions is a " sanity" check of the HEPs. The analyst must review the final HEPs relative to each other to check their reasonableness given the plant history and operational practices and experience. For example, the Human actions with the relatively higher failure probabilities are generally events involving more complex, difficult activities that are performed under more burdensome, time constrained, and stressful circumstances. The Human actions with the relatively lower failure probabilities are generally events performed under more common, routine and straightforward circumstances.

1,6.2 Documentation Requirements The documentation of an HRA must be sufficient that a peer reviewer can reproduce the results. At a minimum, the following information pertinent to the HRA must be documented.

. A list or general description of the plant information that was used in the HRA.

A list of all human actions evaluated (both pre-and post-initiator).

. A list of all HEPs for each human action,

. A list of factors used in the quantification of the human actions, how they were derived (their bases), and how they were incorporated into the quantification process:

- time available versus time required

- dependencies plant-specific PSFs diagnosis and execution.

PRA Standard, D; aft (STANDARD RV3) 1-46

1. Intsrn:I Evants, Full Pcwsr, Lcvsl 1 (Draft) i

. Source of data used to quantify human actions,

. Screening values and their bases.

. Any assumptbns that were made in the human reliability analysis, as well as the bases for the assumptions and their impact on the final results.

(Additionalinformation rney be added.)

-1.6.3 Application Requirements The " level of detail

• in performing the technical analysis is not necessarily needed for each element and requirement as described above in Section 1.6.1; nor is the level of documentation the same for a simple rrndel as listed in the above section for a detailed model. The level of detail needed in the technical analysis and documentation for a simple model versus a detailed model is listed below in fable 1.6.3.1.

(Table to be filled-in.)

Table 1.6.3.1 Application Requirements.

- Element /

Technical Analysis for Simple Documentation for Simple Model-Requirement Model 1.6.4 Peer Review Requirements The requirements for performing the elements of an HRA are provided above in Section 1.6.1. A peer review l

1-47 PRA Standard, Draft (STANDARD.RV3)

e

1. Intomsl Eysnts, Full Powsr, Level 1 (Draft) e is performed that ensures that the technical analysis performed meets the required standards. The enteria used in determining if each specific requirement was edequately performed, whether for a simple or detailed model, is provided below in Table 1.6.4.1, in making this determination, the necessary credentials of the peer reviewer are also provided.

(Table to be filled-in)

Table Peer Review Elementi Criteria for Review Required Credentials of equirement Peer Reviewer (s)

Simple Model Detailed Model l

1.7 Parameter Estimation The parameter estimation PRA-element is required to determine the frequency and failure probabilities of the various events such that actual performance (plant-specific and across-the-industry)is represented by the PRA. For this standard, parameter estimation is separated into seven elements. The requirem3nts for the parameter estimation are dependent upon whether a simple or detailed analysis is performed. These seven elements are:

. A Generic (across-the Industry) Database is provided in this standard that combines data from a wide variety of sources relevant to commercial nuclear power plarit operation in the U.S. This generic database includes an uncertainty distribution for each parameter that is intended to represent the plant-to-plant variability in the data. Therefore it is appropriate for use when no plant-specific data cre available and t.3 the prior distribution, before Bayesian updating, when plant-specific data have been collected and analyzed as discussed in the remaining six elements.

PRA Standard, Draft (STANDARD.RV3) 1-48

f.

l

1. Internal Events, Full Pow;r, Lev:11 (Draft)

Model selection criteria to ensure that data are appropriately selected and analyzed.

'stl.

- ent data rettributes define the specific data requirements and analysis techniques needed for the anal) -..,f initiating event frequencies.

Equipment independent rilure data attributes define the specific data requirements and analysis techniques needed for the analysis of equipment independent failure rate.

Equipment common cause failure data attributes define the specific dat? r?quirements and analysis techniques needed for the analysis of equipment common cause failure.

Out of serv /ce data attributes define the specific data requirements and analysis techniques needed for the analysis of equipment out of service unavailability.

Data analysis integration required to actually evaluate plant data and use it in an integrated PRA.

The elements involved in performing the technical analysir, documentation, and certification are discussed below. The level of detail may vary depending on whether a simple or detailed modelis required. These differences for each technical analysis element are described in Section 1.7.4.

Differences in the documentation and peer review are described in Sections 1.7.2 and 1.7.3 respectively.

1.7.1 Technical Analysis Requirements This section enur.erates the requirements for each of the sevM ~ements used in this standard to describe parameter estimation in PRA. Although a data analysis ca! he organized into a different task structure, the elements listed below always apply.

1.7.1.1 A Generic Database The requirement of this element la expected to be that the generic data used in the PRA be consistent with the database provided here. While there are many reasons for plant-specific data to differ plant-to-plant, generic dau should be the same (with possible minor exceptions among plant types). That has not always bee? the case. For example, among IPEs so-called generic data for particular component failure rates have been found to differ by more than a factor of ten.

This element will include a standard generic database that includes plant-to-plant variability. The sources of data for this standard database should be broad and thorough. Methods for developing the database and definitions of specific parameters must have been consistent with the remaining elements described below.

1-49 PRA Standard, Draft (STANDARD.RV3)

l

1. Irt:rnal Events, Full Power, level 1 (Draft)

Table Generic Database Parameter Plant-to-Plant Variability Sources and Comments Distribution and Statistics 1.7.1.2 Parameter Estimation Understanding The requirements of this element are discussed under two topics:

. Understanding the issues affecting parameter estimation

. Analysis methods 1.7.1.2.1 Understanding the issues Affecting Parameter Estimation This section will be. written to identify the key requirements associated with the development of parameter estimatesy(l.e., a database and its associated information) suitable for use in a PRA that is to be used for decision-making and risk-informed regulation. It will include at least the following issues:

• Familiarity with potential pitfalls in data development and usage Generic and plant-specific data e

Sources of generic data

- The need foe single combined generic database Sources of plant-specific data PRA Standard, Draft (STANDARD.RV3) 1-50

C_,,

[

L

1. Intsmal Evants, Full Pow r, Level 1 (Draft)

- a Interpretation of plant-specific data s Source motorial and soplicability to PRA 4 Raw data versus processed data

+ Uses of the data 1.7.1.2.2 Analysis Methods

%nt cus methods for date analysis will be addressed along with specifications of the most appropriele methods for partcular applications The range of methods willinclude Bayesian methods, engineenng and ststletical tests forzgrouping (pooung) data, parametric common cause methods,_... Typical.pmblem areas vill be discussed, identifying vertfloation procedures to ensure proper handling of the data / In short, this section will identify the requirements proper use of available methods and common errors that rr,ust be avoided.

The leeue,of unootteinty in the parametar estimates will be. explained in this section, along with the requirements for treating it.

1.7.1.3 initiating Event Data Attributes This task estimates the frequency of occurrence (per reactor year) for each transient, LOCA and loss of support system event defined in the initiating events analysis (Section 1.2). For transient events, the number and nature of plant scrams and unplanned shutdowns and the hours the generator is no line must be identified. This information is identified from actual plant-specific scram reports, LERs, For initiators where there are few or no plant-specific events, generic initiating event frequencies (see Table i must be used for establishing prior distributions for Bayesian updating with available plant-specific data.

Certain initiator frequencies (e g., loss of support systems) may need to be estimated by constructing and quantifying plant-specific system (fault tree) models. Such models must be developed differently from the f

typical system unavailability models as described in Section 1.5.

1.7.1.3.1 initiating Event Definitions This section will define initiating events in general and each particular type. -11 wP describe how exposure times should be developed for each type of initiator (e.g., whether calendar time or reactor operaton time at power should be used).; Where attemative approaches for addressing initiating event data (e.g., loss of off-site power dets) exist, they will be discussed.

1.7.1.3.2 Data Applicability This section will describe the requirements conceming the applicability of particular data for use in the PRA.

Examples of topc3 to be included include:

+ Time period for collecting data-minimum time, inappropriate interval selection,...

• Causes; l.e;, low level definitions

• Plant response to tbs initiating event 1

1-51 PRA Standard, Draft (STANDARD.RV3)

1, Int: mal Ev:nts, Full Pow:r, Lcytt 1 (Draft) t L

1.7.1.3.3 Data Grouping The appropriate reasons for grouping data will be discussed along with caveats for avo; ding well-known problems.

1.7.1.3.4 Data Screening Screening must always be approached carefully to avoid losing knportahlinformation and biasing results. I he appropriate bases and caveats will be presented.

1,7.1.4 Equipment independent Failure Data Attributes This task estimates the equipment's unreliability (i.e., equipment fails to function or fails to continue to function) and the equipment unavailability (i e., equipment is unavailable to function because it is out of service).

1.7.1.4.1 Failure Data Definitions This section willinclude definition of factors involved in the development of equipment failure rate data, including those affecting identifu. don of the number of failures and those affecting the numoer of successes (or the successful run time). The issues described in the following text will be refined and expanded for this standard.

The relevant parameters for equipment reliability are the demand failure probability (for standby equipment, required to start or change state), and the operating failure rate (for equipment that must operate for some time after an accident or transient to mitigate its effect or impact.) The preferred method for estimating equipment reliability parameters is Bayesian updating in which generic data are used as a prior distribution and updated with plant-specific data. Generic data sources must be representative of the plant components and the nature of the failures and demands in the pooled data set must be consistent with the plant-specific applications modeled in the PRA. Generic data used in the model would be pedigreed and justified for the cpplicability to the specific-plant under study. The component boundaries and failure modes defined in the model are to be consistent with those in generic and plant-specific data. EPRl/TR-100381 (Ref.1.4) provides useful information on the process for data collection, and reduction along with examples of equipment boundaries. The raw data needed to estimate these parameters are the number of demands, the number of demand failures, the number of failures observed while running, and the running (operating) time.

In quantifying component reliability, actual demands and those that reasonably approximate conditions for the required accident / transient response must b6 used. For those cases where demands are not normally tracked (e g., using a safety pump to regularly fill a tank), demands can be estimated based on establishing a representative history. Demands and the associated failures must be collected and tabulated by the nature of the demand (i.e., actual, spunous, type of test, etc.). Pooling demands and associated failures can be done when (1) the nature of the demands are similar, (2) the nature of the failures are similar, and (3) the failure probabilities from the pooled sources represent similar statistical populations.

Data used in the component failure probability estimations must be representative of the current component design and operajon. Therefore, failure events may be examined in detail to show if plant modifications have eliminated the types of fai!ures previously identified and have not introduced other credible failure mechanisms PRA S*1ndard, Draft (STANDARD.RV3) 1-52

s

1. Intemal Events, Full Power, Level 1 (Draft) d not previously observed. Failures recovered promptly fron1 the control room such that the function of the component was not comoromised can be excluded as failures from the data set, provided that the model does not credit such recovery elsewhere. Repeated failures occurring within a small time interval must be counted as a single demand and a single failure if there is a single, repetitive problem that causes the failures. (For example, if a valve fails to open and subsequently receives multiple demands to open, only one failure and one demand must be counted ) For failures discovered by means other than a valid demand, the er,uipment unavailability resulting from such a failure must be counted against the accumulated equipment unavailability.

(For example, an operator discovers while taking log readings that a pump has no oil in its lubrication reservoir rending it inoperable.)

The failure to run rate is used for operating equipment that must operate for an extended period fol owing a demand. This would normally be a time after which the equipment reached rated speed or voltage and ran long enoegh to be judged a successful start (generally an equilibrium operating state.) The data needed (for equipment normally in standby) are the cumulative hours of operation after a successful start and the number 4

of failures observed during these hours of operation. For equipment normally operating, the data needed are the cumulative operating time and the number of failures observed during these hours of operation. For test surveillance or other demands for which the actual ruh times are distinct!y less than the length of the mission time modeled in the PRA, it must be determined whether the failure r he derived from truncated tests or demands is applicable over the mission time.

The statistical estimation techniques would consider the types of parameters to be estimated, and availability of generic or plant-specific data in " raw" or ' treated" forms. These considerations must also include the choice of prior distribution in case Bayesian techniques are implemented.

Particular issues that can corrupt the data will be discussed, for example:

. Beware of double counting

. Breaking out causes to support special applications from systems analysis 1.7.1.4 2 Data Applicabi!.ty A varltsty of issues that affect the applicability of data for use in PRA will be discussed in this section. Including:

. Use of data from incomplete tests

. System boundaries and data boundaries [EPRl/TR-100381 (Ref.1.5) provides useful information and examples concerning equipment boundaries)

. Time period for collecting data-minimum time, inappropriate interval selection..

. Causes; i.e., low level definitions 1.7.1.4.3 Data Grouping The appropriate reasons for grouping data will be discussed along with caveats for avoiding well-known problems. Too often data are grouped with no consideration given to the basis for such action.

1.7.1.4.4 w Screening 1-53 PRA Standard, Draft (STANDARD.RV3)

l e

1. Int;rnal Events, Full Pow:;r, Lcv:11 (Draft) a Screening must always be approached carefully to avoid losing important information and biasing results. The appropriate bases and caveats will be presented.

1.7.1.5 Equipment Common Cause Failure Data Attributes Options for estimating common cause failure (CCF) parameters are: (1) the Beta factor model (note that for most applications a more complete model is required), (2) the Basic Parameter Model, (3) Alpha factor models, (4) the Multiple Greek Letter model, and (5) the Binomial. are rate model. The data needed for estimating common cause failure probabilities are the numbp4f independent failures and the number of multiple failures due to a common cause. Since there is generally insufficient data to derive plant-specific estimates of the common cause failure parameters, generic data must be used. However, the generic data must be evaluated to determine their applicability to a specific plant. In those cases where some plant-specific data are available, they can be used to update the generic data with Bayesian methods, f

Common cause modeling is highly interactive between parameter estimation and system modeling (Section 1.5) and it is important to insure that the systems and data models are consistent.

1.7.1.5.1 Common Cause Fai'ure Definitions Definitions used in common cause modeling will be described in this section. It is important to fully understand these definitions to properly apply the more complex approaches for common cause modeling. Among the issues to be included are:

• Parameterdefinitions

• Impactvectors 1.7.1.5.2 Data Applicability This section will describe the requirements conceming the applicability of particular data for use in the PRA.

Examples of topics to be included include:

• Causes; i.e., low level definitions

. Scaling up and scaling down when the redundancy in the analyzed plant differs from that in the plant where the failure occurred 1.7.1.5.3 Data Grouping The appropriate reasons for grouping data will be discussed along with caveats for avoiding well-known problems. Too often data are grouped with no consideration given to the basis for such action. In addition, for common cause modeling, the issue of defining common cause groups in the sys%ms model arises.

1.7.1.5.4 Data Screening Screening must afways be approached carefully to avoid losing important information and th. sing results. The appropriate bases and caveats will be presented. For com non cause dats there are several special PRA Standard, Draft (STANDARD.RV3) 1-54

\\

m

1. Internal Events, Full Power, Level 1 (Draft) l

• issues-while it is appropriate to screen failures that are impossible at the plant under consideration, it is important to ensure that no similar kind of failure (that may not have happened) is possible. The distinction between generic and plant-specific data has been lost occasionally in the consideration of common cause failures; i.e., just because a particular common cause failure has not occurred at this plant is not sufficient reason to screen it froni the generic data. Also, cause-ociense thinking often makes it tempting to screen failures because a defense has been put in place, i.e., imperfect defenses are considered to be perfect.

1.7.1.6 Out of Service Data Attributes Out-of-service unavailability data are needed for equipment remuved from service for planned or unplanned repair or testing. The data required are the out-of-service time for each component and the total time the component is required to be operable. Coincident outage times for redundant equipment (both intra-and inter-system) must be examined and accounted for based on actual plant experience. Calculations of outage unavailabilities must raflect actual plant experience.

1.7.1.6.1 Out of Service Data Definitions This section will include definition of factors involved in the development of equipment out of service unavai! ability data, including:

. Define maintenance rate and duration

. Interpreting plant maintenance records 1.7.1.6.2 Data Applicability A vanety of issues that affect the applicability of data for use in PRA will be discussed in this section. Including:

. System boundaries and data boundaries

. Time period for collecting data-minimum time, inappropriate interval selection..

1.7 Data Grouping priate reasons for grouping data will be discussed along with caveats for avoiding well-known problems. Too often data are grouped with no consideration given to the basis for such action.

1.7.1.6.4 Data Screening Screening must abuays be approached carefully to avoid losing important information and biasing results. The appropriate bases and caveats will be presented.

1.7.1.7 Data Analysis integration This section will describe the requirements for data analysis integration including:

. Proper use of generic and plant-specific data

. Bayes updating; are posteriors consatent with priors?

1-55 PRA Standard, Draft (STANDARD.RV3)

e l

1, internal Evrnts, Full Pow 2r, Level 1 (Draft) 4 Coordination with systems modeling Imbeddinc parameter estimates in PRA computer codes 1.7.2 Documentation Requirements The following information must be included in the ORA documentation.

. The initiating event frequencies.

. The distribution for demand failure probability, standby failure rate, failure-to-run failure rate, and equipment out-of service unavailability (as applicable) for each event.

. System and component boundaries, mission times, and reliabilib models used.

/

. The sources of raw data, generic data, and other information used in estimating initiating event frequencies, equipment reliability, or CCF probabilities.

. The time period from which plant-specific data were gathered.

. Key assumptions made in the data analysis. (The bases for the assumptions and their impact on the final results must be discussed in the sensitivity analyses )

. Raw data records and related interpretations of those records used to derive the data values must be available for review.

. Rationale for and distributions used as priors for Bayesian updates.

1.7.3 Application Requirements The complete " level of detair in performing the technical analysis is not necessarily needed for each element and requirenient as described earlier in this section. Similarly, the level of documentation will not be the same for a simple model as it would be for that listed in the above section for a detailed model. The level of detail needed in the technical analysis and documentation for a simple model versus a detailed model is listed below in Table -

Table Application Requirements Elementl Technical Analysis for Simple Documentation for Simple Model Requirement Model PRA Standard, Draft (STANDARD.RV3) 1-56

Q 4

e 0

d

.n

_ _. _.