ML20062C964
| ML20062C964 | |
| Person / Time | |
|---|---|
| Issue date: | 10/26/1990 |
| From: | Taylor J NRC OFFICE OF THE EXECUTIVE DIRECTOR FOR OPERATIONS (EDO) |
| To: | |
| References | |
| SECY-90-365, NUDOCS 9011050059 | |
| Download: ML20062C964 (85) | |
Text
.
s y ~%
. RELEASED TO THE PDR -
[ J/hl,sh0 h
g dals inUdlS I
5 i-g
. ooeoseeeeeeeeeeeeeeeeee
% 5.***+*
4 October 26, IMO I
SECY-90-365 (Informat. ion)
=
For:
The Concissioners From:
James M. Taylor Executive Director for Operations Sub.iect:
DESIGN DOCUttENT RECORSTITUTION PROGRAMS INITIATED BY-UTILITIES
Purpose:
To inform the Commissiontrs cf the staff's actions regarding-utility-initiated desigi' document reconstitution (DDR) programs and the " Design Basis Program Guidelines" document developed by theNuclearUtilityan;llanagementResourcesCouncil(NUMARC).
Discussion:
Utilities have,. in the last few years, initiated extensive efforts to improve the adequacy and completeness of the set of desigh bases, design analyses, and final design output documents that define the design for their facilities. The principal reason for these initiatives has been the consistent findings of NRC safety-system functional inspections (SSFIs) and safety system cutagemodificationinspections(SSOMIs)thatsomelicenseeshave made inappropriate plant modifications which have affected the functionality of safety systems. These modifications were made without the licensee having a: firm understanding of the available-design margins and the stffect that the modifications have on the e margins.
The NRC inspection findings have heightened _the industry's awareness of the need to improve the adequacy and availability of design documents including > design bases, supporting calcula-tions, and final design output documents.
These findings prompted many licensees to review their design documents and reconstitute needed information. However, until recently, the industry has lacked guidance on the conduct of design document reconstitution programs.
In response to this need for guidance, NUMARC has developed the guidance document, " Design Basis Program Guide-lines," that will be sent to NUMARC members within the next few NOTE:
TO BE-ImDE PUBLICLY AVAILABLE IN 10 WORKING DAYS FROM THE DATE OF THIS PAPER CONTACT:
Eugene V. Intro NRR
\\
492-0953 p o s oc s f'
D-lf
\\
The' Comi'ssioners
- l wee ks. This document is the product of an extensive effort by NUMARC and includes the results.cf numerous interactions between the NRC staff and NUMARC during which the NRC staff provided l
comments on drafts of the guidance document.
By letter of July 2,1990, NUMARC provided a June 29, 1990 craft of the document for our review.
Following our review of this i
document, NUMARC agreed to make several-changes in the guidance on reportability of. discrepancies to the NRC.
On August 7, 1990, we met with NUMAP.C representatives to discuss the guidelines.
After our review, we concluded that the NUtiARC document provides a sufficient basis for utility DDR programs.
However, we requested that NUMARC consider an initiative such that each utility would assess its need to begin a DDR program.
1 The cognizant NUMARC working group convened in September to consider the NRC staff's request for an initiative. NUMARC has informed us that they do not see a need for an initiative since most utilities are already performing such programs. NUMARC has-expressed its intent to issue.the guideline document at the end of October 1990.
The staff understands NUMARC's concern with an-initiative and agrees that each utility should select'a scope and approach for its program that are best suited to the individual utility's needs. The NUMARC guidelines provide for.this approach.-
The-latest version of the guidelines document is provided in.
The staff conducted a survey of six utilities and one nuclear steam supply system vendor to determine the status of design control programs within the industry and the strengths and l
weaknesses of a sample of utility approaches to producing and maintaining design bases documentation. The results of this survey will be published.as NUREG-1397, "An Assessment of Design Control Practices and Design Reconstitution Programs in the Nuclear Power Industry." The survey report will contain factual information regarding programs as'they were being implemented at _
that time.
It will describe program strengths and weaknesses and problems encountered by utilities.
Because the staff agrees with the NUMARC guidelines and recommended approach subject to effective implementation, it is not necessary for the staff to proceed with new requirements at this time. :Rather, the staff will continue its inspection activities, and will require corrective action by. individual licensees for specific design basis documentation deficiencies identified as causing safety system functionality problems. ; We believe this is anLappropriate and effective means to evaluate the l.
results of DDR programs. We do not plan a separate _ inspection i
The'Commi'ssioners
-3 :
effort to review programmatic implementation of utility-initiated-DDR efforts because such an inspection activity may discourage-utilities from voluntarily. participating in DDR programs and would-focus on the particular process rather than the results of the process., a meraorandum from Thomas E. Hurley, Director of NRR, to the Regional-Administrators, describes.the staff position in more detail.-
! is a aroposed draft of the final assessment of the NUMARC document t1at the staff will provide by.a letter to NUMARC.
As an enclosure to the draft letter, we. provide comments on i
utility DDR programs related to the technical review of available
'I design documents, the concept of essential-documents, the-prioritization of missing or inadequate documents.and a..
co.nparison of design bases and documect reconstitution. NUMARC-intends to-include our letter with the transmittal of its guidance document to meraber organizations..In this way, each member will-also have the benefit of considering the NRC. staff's views on the guidelines.
In an October-10,1990 letter, NUMARC requested that the NRC-staff participate in industry workshoas on design document reconstitution. The ' workshops. are scleduled for November 27 and December 5,-1990. Senior. staff from NRR willLparticipate in these workshops.
We consider the reconstitution of design documents to be a significant activity-.that increases assurance of safe nuclear power plarit operations. We will continue to support the indus-try's efforts in this area and to examine the engineering results of these programs.
l 7_ f.
s H.-T or xecutive irector; for Operations-
Enclosures:
- 1. Transmittal of " Design Basis Program Guidelines" DISTRIBUTION:
i
- 3. Memorandum from T. E. Murley to OIG Regional Aoministrators GPA REGIONAL OFFICES EDO W'RS ASLBP ASlAP
-SEC/
'l I'
, 4 % ey g g g g gg g gg g igep gj (
l Design Basis Program Guidelines i
October 1990 Nuclear Management and L
Resources Council, Inc.
1776 Eye Street, N.W.
Washington, DC 20006-2496
r, e
DESIGN BASIS PROGRAM GUIDELINES t
i
+
i i
I l
1 l
l l
j OCTOBER 1990
\\
1 ACKNOWLEDGEMENTS The Design Basis Program Guidelines were developed by the NUMARC Design Basis Issuet Working Group.
Input to the development of the guidelines was also provided by the Institute of Nuclear Power Operations (INPO) through its
" Draft Reoort on Desion Basis Information Enhancements in the Nuclear Utility Industry", December 1989, and by the Region V. Engineering Managers Forum through its " Guidelines for the Establishment of Desion Bases Documentation Er.oarams",May 19, 1989.
l l
l NOTICE This information was prepared in connection with work sponsored by the Nuclear Managemerit and Resources Council, Inc. (NUMARC).
Neither NUMARC nor any of its employees, members, participants or consultants make any warranty, expressed or implied, or assume any legal liability or responsibility for the accuracy, comoleteness or usefulness of any information, apparatus, product or process disclosed in this document, or represent that its use would not infringe privately-owned rights.
The opinions, conclusions, and recommendations set forth in this document are those of the authors and do not necessarily represent the views of NUMARC, its employees, members,. participants or consultants.
I e.
o
~
j
}
EXECUTIVE
SUMMARY
The Design Basis Program Guidelines were developed by the Nuclear-Management and Resources Council (NUMARC) Design Basis issues Working Group.
This working group, chaired by David Hoffman, Vice President of Nuclear Operations, Consumers Power Company, is comprised of 21_ individuals representing 12 utilities, 4 NSSS vendors, 4 architect-engineering firms, and the Institute of Nuclear Power Operations (INPO).
The guidelines represent a consensus approach to implementation of a design basis program that builds upon proven utility practices.
These guidelines are offered to NUMARC members for their voluntc ~ use as appropriate.
Consistent application of the guidance in Section'll -
Definitions,Section III - Design Basis Documents, and Section V - Addressing Discrepancies, is recommended to foster a common understanding of design basis q
efforts in the nuclear industry. The remaining sections provide useful information and good practices that should benefit utility design basis programs. Members are encouraged to use the guidelines as a reference point from which to review their existing or planned efforts..
The basic premise of the guidelines is to organize and collate a nuclear power plant's design basis information consistent with the definition of h
design bases contained in 10CFR50.2.
This information should be strictly i
focused on the specific functions and values of controlling parameters that bound the design of structures, systems and components.
in addition, the guidelines promote the collation of supporting design information that provides the rationale for the design bases.
Together, the design basis information and supporting design information, collated in a design basis document (DBD), may serve as a valuable reference to support various plant activities, and may also enhance existing design control and configuration management practices.
A section is included on definitions that provides concise language on terminology related to design bases. These definitions seek to simply convey the meaning of these terms and to effectively communicate each concept. A diagram on terminology relationships is included to illustrate how the concepts fit together.
A sectf on is devoted to lessons learned in developing DBDs.
This section was developed using the experience of several utilities who have implemented design basis programs along with information collated by INP0 through workshops and site assistance visits. This section attempts to capture various utility practices that have proven effective in developing DBDs.
It may prove useful both to utilities in the process of planning a design basis effort and to those who may wish to fine tune their existing programs.
Those utilities with mature design basis programs recognize that the discrepancies identified by their efforts may pose a significant challenge. A section is. devoted to guidance on addressing discrepancies and provides a managed approach to this process. The concept of a presumption of operability i
I n-is promoted that credits broad engineering experience and judgement in cases where incomplete documentation is available. Another key aspect of this section addresces reportability determinations and how "outside the design basis of the plant" may be interpreted.
The process described in this section may be adapted to existing utility processes that address non-conformances or
'3 may be used as a stand alone process.
Validation, maintenance and control of DBDs are important to providing a reliable basis for the application of DBDs.
The validation elcinent provides assurance that the design basis information is consistently reflected in the physical plant and those controlled documents used to support plant operations. Without maintenance and control of DBDs, the documents may quickly lose their value as a reference to support plant activities. A section of the guidelines highlights key aspects of validation, maintenance and control of DBDs that should be considered in an overall program.
Design basis efforts need to consider existing desi".n control and configuration management practices in order to be suc;
^
A section is included that discusses the integration of the design baan effort with these practices. By providing a foundation of design basis information and supporting design information, the design basis effort can supplement and support design control and configuration management, thereby enhancing plant operation, w
I ii
i-.
1 i
TABLE OF CONTENTS
~
Section ELqg j
I.
INTRODUCTION................................................
1 II.
DEFINITIONS................................................
5 I
III. DESIGN BASIS DOCUMENTS.....................................
9 IV.
LESSONS LEARNED IN DEVELOPING DESIGN BASIS DOCUMENTS.......
13 V.
ADDRESSING DISCREPANCIES..................................
25
)
VI.
DESIGN BASIS DOCUMENT VALIDATIO,a.MA'ai'ENANCE AND CONTROL..
39 VII. -INTEGRATION OF DESIGN BASIS PROGRAM WITH CONFIGURATION MANAGEMENT AND DESIGN CONTROL..........
41 APPENDIX A: EXAMPLES OF REFERENCES FOR DESIGN BASIS INFORMATION..
43 APPENDIX B: EXAMPLES OF DESIGN BASIS INFORMATION.................. 45 APPENDIX C: EXAMPLES OF SOURCES OF SUPPORTING DESIGN INFORMATION..!47 APPENDIX D: EXAMPLES OF SUPPORTING DESIGN INFORMATION............
49-APPENDIX E: _ POTENTIAL DBD APPLICATIONS...........................
53 APPENDIX F: OTHER TYPES OF INFORMATION TO CONSIDER FOR DBDs......
57 iii mm
t
~
TABLE OF CONTENTS Section EA,gg i
I.
INTRODUCTION................................................
1
{
II, DEFINITIONS................................................
5 1
III.
DESIGN BASIS DOCUMENTS.....................................
9 IV.
LESSONS LEARNED IN DEVELOPING DESIGN BASIS DOCUMENTS.......
13 V.
ADDRESSING DISCREPANCIES...................................
25 VI.
DESIGN BASIS DOCUMENT VALIDATION, MAINTENANCE AND CONTROL..
39 VII.
INTEGRATION OF DESIGN BASIS PROGRAM WITH CONFIGURATION MANAGFMENT AND DESIGN CCNTR0L..........
41 I
APPENDIX A: EXAMPLES OF REFERENCES FOR DESIGN BASIS INFORMATION.. 43 i
APPENDIX B: EXAMPLES OF DESIGN BASIS INFORMATION..................,5 I
APPENDIX C: EXAMPLES OF SOURCES OF SUPPORTING DESIGN INFORMATION., 47 APPENDIX D: EXAMPLES OF SUPPORTING DESIGN INFORMATION............
49 l
s L
APPENDIX E: POTENTIAL DBD APPLICATIONS............................-53 1
APPENDIX F: OTHER TYPES OF INFORMATION TO CONSIDER FOR DBDs......
57
.. i iii
v f
l.
~
1,.
INTRODUCTION Dur ng recent years, extensive resources have been allocated by utilities towards the development of design basis programs.
In an absence of defined recuirements regarding the content and scope of this area, utilities ',.we putsued programs tailored to meet their particular nuclear power plant vintage,! sds, and intended applications. This has resulted in a variety of approaches and formats for the collation of plant design basis information and supporting design information.
NUMARC establis'.ed the Design Basis Issues (DBI) Working Grwp to :ddrett the ulezr need to develop an approach built around the many activities presently l
underway by utilities that addresses both industry and regulatory concerns in this important area. One of the specific goals of the DBI Working Group is to review industry experience regarding the devalopment of design basis programs and provide guidance that captures the practices that have proven effective.
Thu document is aimed at meeting this goal.
The intended purpose of these guidelines is to provide gu. dance for the development of a design basis pregram that collates design basis information and supporting design information, not to identify or recreate the licensing basis for a plant.
It is recognized that some design basis information may bs, coincident with licensing besis i' formation.
The primary focus of this document is to address the intent, content, development, and uses of design basis documents (D80s).
Configuration management and design control are also discussed since they are logical outlets for the information collated by a design basis program.
To effectively communicatt the concepts and interpretations of the various elements of design bases, the DBI Working Group has adopted a list of definitions and relationships between the applicable terminology. These are presented in Section II, Definitions, 1
$h
M Sp tion !!!, Design Basis Documents, addresses the intent of DBDs, design basis information, supporting design information, and the objectives of DBDs.
j This section promotes the development of a program that collates a plant's design basis information consistent with the design basis defin: tion containti in 10CFR50.2 and that captures the rationale or the "why" information behind a plant's design bases. The objectives of DBDs are based on a summary of the primary applications of DBDs that were identified through a nuclear industry survey conducted by NUMARC.
These applications are focused in the engineering and licensing areas.
I Lessons learned in develeping DBDs is provided in Section IV.
This section focuses on the administrative aspects of design basis programs.
Topics discussed include organization, resources, pilot efforts, user input /needs, format / content, source information search and retrieval, procedures / writer's guide, and scope / planning / scheduling. The content of this section was derived from input provided by INP0 and from utilities on the DBI Working Group.
The disposition of discrepancies identified during the implementation of design basis prngrams is discussed in Section V, Addressing Discrepancies.
Guidance is provided regarding determinations of operability and reportability along with criteria to address the prioritization of discrepancies including missing information.
l Section VI discusses DBD validation, maintenance and control.
Discussed are alternatives for validating information contained in DBDs, along with proper indexing and cross referencing of pertinent documents and the medium used to store, retrieve, and edit these documents.
l The need to consider configuration management and design control in conjunction with des aoping a design basis program is discussed in Section Vil, Integration of Design Basis Program with Configuration Management and Design Control.
Highlighted are key aspects of configuration management and design control that are essential to the effective application of DBDs while ensuring consistency between the design, physical plant and the controlled documents that support plant operation.
2 w
or
.w,,,
+---cw w,-
t e
i T,he guidance contained in Section II - Definitions,Section III Design Basis Documents, and Section V - Addressing Discrepancies, is intended as information that will facilitate a common understanding of design basis programs within the nuclear industry and with the regulator.
Consistent l
application of this guidance is recommended. The information contained in Section IV - Lessons Learned in Develcoing DBDs,Section VI - DBD Validation, Maintenance and Control, and Section VII - Integration of DB Programs with Configuration Management and Design Control captures many of the " good practices" that have proven effective in the past at various utilities.
This information can prove to be useful in the development of an efficient, thorough program and should help to achieve program objectives.
'I 3
I 4
e
o u__.,...
m.
m
~.,_ __-.
m.
__ _ m
-m.
~
n t
g e.
b 9
0 6
?
h E
r
}
1 1
l l
J l
4 1
1 i
d W
I 2
e ff M ttN M
a e
-r#
e
..n.-m-<.-
- - som m, en ch-,..
m m.
,h Mc m-m 7 l
l' -
\\
I,I.
DEFINITIONS I
l 1.
DESIGN BASES:
Information that identifies the specific functions to be performed by a structure, system, or component of a facility and the specific values or ranges of values chosen for controlling parameters as reference bounds for design. These values may be (1) restraints derived i
from generally accepted " state of the-art" practices for achieving i
functional goals or (2) requirements derived from analysis (based on j
calculations and/or experiments) of the effects of a postulated accident for which a structure, system, or component must meet its functional goals.
(10CFR50.2) 2.
DESIGN CONTROL: Measures established to assure that the information from design input and design process d' ocuments for structures, systems, and components is correctly translated into the final design.
3.
CONFIGURATION MANAGENENT:
Integrated process of maintaining the physical plant and those controlled documents required to support plant operations consistent with selected design documents.*
4.
DESIGN INPUT:
Those criteria, parameters, bases, or other design requirements upon which the detailed final design is based.
(ANSI N45.2.11) 5.
DESIGN PROCESS: Documented design practices such as calculations, analyses, evaluations, technical review checklists, or other documented engineering activities that substantiate the final design.
6.
DESIGN OUTPUT: Documents such as drawings, specifications and other documents defining the technical requirements of structures, systems, and componerts.
(ANSIN45.2.ll)
- NOTE:
INPO hac published a report. on configuration management in the nuclear titility industry that notes the major interfaces of an integrated configuration management process.
l l
5
-.._-..--s.s.
~..,, *,. _.. -... _.
,_,..,.,~.--n..
~_.,,-r.
w
)
i 7.
FINAL DESIGN: Approved design output documents and approved changes l
thereto.
(ANSI N45.2.ll) 8.
OPEN ITEMS:
Those items that are discovered during the implementation of design basis program activities that are potential discrepancies and require disposition.
i l
r 9.
VALIDATION:
Process that provides reasonable assurance that design basis information is consistently reflected in the physical plant and those controlled documents used to support plant operations.
10.
DISCREPANCIES: Those open items identified by design basis program activities that are confirmed discrepant and may have potential safety significance.
Figure 1 illustrates the relationship between many of the terms defined in-this section.
Examples provided in the document " boxes" are typical and are not intended to be all inclusive.
l l
l t
1 6
i
,s-
2:
i i
l Figure 1 1
i Terminology Relationships O & M Procedures t
kneucuans
[ Consguradon i
l
( h+wn l-Other Controlled Physical Plant Documents i
Design l
coniroi i
i i
I l
i
"'8" 8'*".
specs caicuiasms i
Reg Regs
_ Drawings Ad,m l
LOlherDagn Roqs Evakudinns Iists i
Design Design Design l
Design input Process Output l
Documents
~
s t'
e e
4 9
4 e
h 1
8 s
i s
N
l. - _ -
\\
r.
t
{l!.
DESIGN BASIS DOCUMENTS l
A.
INTENT OF DESIGN BASIS DOCUMENTS l
The intent of establishing a design basis program is to organize and collate a nuclear plant's design basis information along with supporting design information that provides the rationale or " whys" for the design bases.
The collation of these two sets of information is commonly referred to as design l
basis documents (DBDs) which can serve as a valuable rc2arence for the intended users in support of selected plant activities. Additionally, by providing a standard, well defined, and controlled interpretation of a plant's design bases, DBDs can enhance existing design control and configuration management practices.
Without modifications and plant improvements.'the only documents that would be needed to operate a nuclear power plant would be the operational and maintenance manuals and procedures together with the Technical Specifications and Safety Analysis Report. However, equipment degrades, plants experience l
transients, and modifications and improvements are implemented to increase i
efficiencies and sustain long term operations.
In large complex and interactive designs such as consercial nuclear facilities, a minor alteration could result in the degradation of system performance in the long, or short term, which may reduce the margins of safety beyond the approved envelope.
It is therefore important to collate design basis information and supporting design information for use in selected plant activities that support the continued safe operation of the facility.
B.
DESIGN BASIS INFORMATION As defined by 10CFR50.2, the " design basis" of a structure, system, or component is comprised of that information which identifies the specific functions to be performed and the specific values or ranges of values chosen for controlling parameters as reference bounds for design.
This information i
should be captured such that the following requirements are met:
9
~
r c.
.--.,w... -
-.,-v.
nl t
l.
o The design functional requirements are summarized, and references are provided from which the requirements were identified, o
Where applicable, the specific values or range of values for parameters that bound the design are summarized, and references are provided from which the parameters were j
identified.
o Through the references identifying the design functional requirements and bounding parameters, a comprehensive list of references is generated that support the plant's design
- bases, Appendix A provides some examples of references for design basis information.
f An organized review of a system's functional requirements and controlling parameters will facilitate a complete and consistent collation of the design bases. Design bases should be stated in concise terms strictly limited to the scope outlined in the definition contained in 10CFR50.2 ti.e., focused on the specific functions or controlling parameters that bound the design).
An example of a collation of design basis information is provided in Appendix B.
This information should be used with appropriate input from the design authority.
C.
SUPPORTING DESIGN INFORMATION In providing the reasons why particular design bases exist, the supporting design information establishes and maintains an understanding of the design j
bases that enables successful accomplishment of key program objectives.
The level of detail provided in the supporting design information should be directly related to the intended users' needs in supporting the program objectives.
10 i
~
-. ~,
n w
1(
Supporting design information should provide the rationale or " whys" that support the design bases of a nuclear power plant. This information may come from a variety of sources.
Examples of sources of supporting design information are provided in Appendix C.
The supporting design information should be distinguished from, but linked to, the design basis information.
It is advantageous to distinguish these different sets of information in order to avoid potential confusion regarding reportability determinations for design basis related discrepancies.
Section V, Addressing 01screpancies, provides additional information on reportability determinations.
Tne organization ed collation of supporting design information can prove to be extremely useful in support of selected plant activities.
This information should expand on the design basis information to assist in evaluating the impact of modifications or procedure changes on the design bases for systems, components or structures. Additionally, the supporting design information can be used to assure conformance with regulatory requirements while facilitating nore efficient working practices.
Examples of :.gporting design information are contained in Appendix 0.
This information should be used with appropriate 17put from the design authority.
D.
0BJECTIVES DBDs can be used tt, support a variety of plant activities.
However, without a clear sense of the objectives that the DBDs are developed to achieve, the program could produce documents of minimal value to the intended users.
- Thus, it is imperative that objectives be identified as an initial step in the program. As DBDs are developed, they should be evaluated by the degree to which they fulfill the program objectives.
l The following objectives are recommended for design basis programs. These objechives represent primary applications of DBDs as identified through a nuclear industry survey conducted by NUMARC:
11 1
n) o Provide a documented reference for engineering personnel to j
use in the design process when considering future plant modifications, o
Serve as a basis for technical reviews, safety reviews, and 10CFR50.59 safety evaluations, o
Provide a documented reference to support operability evaluations and determinations for continued operation.
o Provide a documented reference for licensir personnel in support of licensing analyses and updates to safety analysis
- reports, o
Provide a documented reference to support the review of Technical Specifications changes.
The above objectives are certainly not all inclusive. They are targeted on the engineering and licensing areas as the primary beneficiaries of DBDs.
There are many other plant activities that may benefit from and be an oojective for a design basis program.
Appendix E provides a list of potential applications for DBDs that have been identified by utilities.
These applications may also serve to provide useful program objectives. One should be advised, however, that targeting too many applications as primary objectives can obscure the focus of the program.
There may be benefits derived in other areas not specifically targeted by the program.
Productivity improvements have been realized by many utilities for l
many different applications of DBDs.
The magnitude of any benefits will be contingent on the depth of the program.
12
- _ ~.
4 i.
,I V.
LESSONS LEARNED IN DEVELOPING DESIGN BASIS DOCUMEELi The management of design basis programs requires careful planning and effective controls to ensure that the effort is credible, timely and cost effective.
There are many important administrative aspects to consider in developing DBDs that can impact the successful completion of the project.
The following subsections provide information that has been gleaned from utilities that have mature programs in place. The intent is to convey the " lessons learned" from such programs in order to facilitate other utility efforts.
A.
ORGANIZATION A senior management policy should be established that identifies a utility's lead organization for the development ar.d maintenance of the effort.
The policy should define the organization and appropriate accountabilities for development an'd implementation of the effort.
The lead organization should be given the authority to carry out all aspects of this responsibility.
A single individual (e.g., project manager) should be assigned the responsibility to organize and manage the project team and for overall project management. The project manager should have the authority to interface with appropriate department heads to ensure a streamlined flow of information and to effectively manage the available resources.
The project organization should consist of project team members who are l
assigned full time and, if necessary, are matrixed individuals. The project team membert should represent the departments affected by the design basis program and the anticipated users.
Ideally, the members would have both sufficient experience and authority to speak for their respective departments concerning program decisions.
The project organization and the project manager should have the full support of senior management.
This will ensure a true understanding of the utility's and senior management's commitment to the project.
13
,m
..-n-a e
,----o
i i
l.
B.
RESOURCES l
l A design tasis program may require substantial resources from the utility even if a contraciar is actually developing the documents.
Utility support is required for various activities such as record searches, document review and comment, program management, question response', and discrepancy resolution.
l l
Development of 4 comprehensive set of DBDs may require several years to l
complete. This can result in significant financial commitment requiring utility management support and monitoring throughout the project. The project should be included in the utility's long-range planning to ensure a timely and credible completion of the project and subsequent maintenance of DBDs.
With regard to staffing the project team, the direct participation and involvement of utility personnel can result in significant benefits to the utility. The key goals should be to promote ownership of the products developed and to maximize the retention of knowledge gained during the project assignments. Attainment of these goals should help to ensure proper usage and application of the DBDs developed and also increase the productivity for each l
application.
Proper selection of the project team is vital to the success of the project.
Since the design bases and supporting information may involve a mixture of original plant design requirements together with other rcauirements imposed or adopted up to the present, it is important to consider including engineers experienced in design and regulatory requirements when the plant entered commercial operation as well as engineers experienced in current design and regulatory requirements. Consideration should also be given to including personnel familiar with the Nuclear Steam Supply System (NSSS) vendor and the original Architect Engineer (A/E).
A team of individuals, such as utility, NSSS, and A/E personnel under utility management, organized to develop and review DBDs should enhance utility knowledge of design basis requirements and promote subsequent ownership by the utility.
14 n
,C.
' PILOT EFFORT DBD programs should commence with a pilot phase intended to develop the basic program process, initial cost / schedule data, format / scope, and user interfaces.
This will allow for testing the adequacy of project procedures to ensure development of consistent work products and satisfaction of project goals and objectives before the start of full scale DBD production and further expenditure of resources.
i The pilot phase should establish the program elements, the progra*, process, and organize resources as for the full scope effort.
Following completion of the pilot effort, utility management should assess the usefulness of th*
product prior to deciding the final scope, schedule, and resources needed.
The pilot phase should provide factual information needed to make decisions regarding the level of effort, objectives, approach, and the types of DBDs to be developed. To sample a wide range of potential DBDs, the following areas are recommended for inclusion in the pilot effort:
o a system designed by the NSSS supplier; o
a safety related system designed by the A/E; o
a nonsafety related system designed by the A/E; and a topical area, such as Seismic or Fire Protection.
Pilot efforts are also beneficial in determining the appropriate controls necessary for maintenance of DBDs, managing. discrepancies and methods for controlling design basis information and supporting design information.
D.
USERINPLIT/NEEDS Design basis programs should provide controlled user-friendly information to the end users as defined by the utility. Any group, department, or organization designated to be an end user of the product should participate in the determination of scope, establishment of objectives, level of detail, and the review of the LBDs. This participation is essential to developing a sense 15 e
e e,, - -
,-._y,
,,_,.,..,,.,,,,,w_,,n--m
,.,-wn,,,
n
-w-
=
of ownership in the products developed and will also promote usage of the products.
Acquiring early input from end users is cruc'.a1 for the DBD effort to fully realize the program objectives. This shornd include the involvement of 1
various engineering disciplines (plant and corporate) that use design information. Their input and feedback is imperative from the start of the project.
E.
FORMAT /CDNTENT As discussed earlier, a DBD may consist of both design basis information and supporting design information.
The approach taken to presenting these sets of information can vary depending on a myriad of factors, such as plant vintage and design, user needs, topic of the DBD, and availability of information.
Thus, the type of DBD developed should be tailored to meet the individual needs and constraints of the utility. The purpose of this subsection is to provide general information on the format and content of DBDs that may assist in developing an effective approach.
The subject of the DBD should not be bounded by any particular facet of a power plant's design. However, physical boundaries of a system should be delineated prior to the start of DBD development.
The DBD may address structures, systems, components or topical design considerations such as seismic, environmental qualification, fire protection, high energy line break, etc. While topical information may be addressed either within system DBDs or separately, many utilities have found that separate topical DBDs reduce redundancy in that the system DBDs can reference tt,a applicable topical DBDs.
This approach also helps to ensure consistent application of the topical information.
The DBD subjects should be selected based on their importance to plant safety, reliability, an/ dYailability. A prioritization scheme for DBD subjects should be dei 7 ped based on the above factors.
16
t DBDs can be formatted into three basic types of documents:
1)
Comorehen it:
provides extensive text on:
t o
design bases l
o supporting design information o
component information o
calculation summaries 3
o related drawings and specifications o
codes and standards by reference, date and applicability Minimal cross-referencing of documents is included..
2)
Index - provides minimal text with extensive references to other documents.
References may include:
o system descriptions o
calculations o
specifications o
other documents r
o codes and standards 3) liixtd - includes descriptive text plus extensive references.
For example, a mixed approach may include texts of:
o design bases o
supporting design information o
component descriptions With references to:
o calculations o
specifications o
codes and standards o
other documents i
17
+e..,-,..v-,
,-,---,-nn,w.
F' s
Any of the formats can prove effective in presenting the information contained in DBDs.
In general, it is unnocessary to duplicate the contents of other self-contained documents such as:
i o
ASME Code stress reports o
Equipment Qualification data packages o
Vendor manuals o
Operations and Maintenance procedures o
Industry codes and standards o
Specifications o
Generic regulatory requirements o
Calculations The level of detail and other decisions regarding the content of the document developed should clearly reflect the program objectives. While the design basis information in the DBD should be concise, the amount of supporting design information to include in the document is dependent on the intended applications.
l Whatever approach is selected regarding the format and content of DBDs, it is strongly recommended that design bases information be distinguished from supporting design information. This may be accomplished by labeling the diffarent sets of information, highlighting or underlinina the design basis information, or some other comparable technique. This will reduce the potential for onfusion when discrepancies discovered during the implementation of the program are evaluated for reportability, where an item may be construed as being outside the design basis of the plant.
l There are many types of information that may be considered for inclusion in a DBD.
Examples are provided in Appendix F.
18 O
m f
,y.-
y y-
._y
. i F.
SOURCE INFORMATION SEARCH AND RETRIEVAL l
A large factor in the design basis program of a plant is the availability of sources containing design basis information and supporting design information.
i This ir. formation can be found in a variety of sources.
Many of the original design and construction documents for a plant may be stored in warehouse (s) or other files with no easy means of retrieval.
Since these documents may not be indexed and the technical contents not identified, utilities should consider indexing of collected and assembled documents (0B0 references), and should organize this information such that it is readily retrievable in the utility's commonly used information system for future review needs.
This function should be addressed in appropriate project procedures and developed prior to or during the pilot phase.
In order to facilitate the search for information the project team should be provided ready access to interview and interact with appropriate utility personnel to locate, gather and collect information.
Ready access to reproduction and microfilm / fiche machines should also be provided, as well as controlled files, records and archives.
The recovery of design basis information and supporting design information can be resource intensive. As a result, a utility may elect to focus the search and retrieval effort to address problem areas or to where an identified need exists.
Recognizing that some information will be proprietary, proper consideration and planning for handling such material should be undertaken. This may include the review of previous contractual arrangements and/or new agreements.
Information developed prior to imposition of Appendix B of 10CFR50 may be used as the authoritative technical basis for design provided that such information:
o can be logically followed; and o
is pertinent to the current plant configuration.
19 es
-w,
.-y,--,,-,--o.-6..--,
w-
_ _ _ ~ _
o nl No supplementary verifica+, ion may be necessary if the neve attributes are present.
The program ad'ainistrative procedures should provide specific utility requirements fo use and incorsoration of this information.
The intent is to provide renonable assurance that the recovered information is credible.
G.
PROCEDURES / WRITER'S GUIDE Administrative procedures consistent with the established policy are needed to effectively implement a design basis program.
The development of procedures establishes management control over the process to be used to develop, review, and approve the documents and ensures appropriate standards are established and communicated.
Development of project :pecific procedures to control the technical, interface and administrative work prior to the start of the collation process is essential to the successful and cost effective completion of the project.
These procedures should be written to ensure a consistent approach to the development of each DBD.
Procedures should be prepared to address and control responsibilities associated with document preparation, review and approval processes, and long-term handling and control of completed documents.
The following are typical topics that should be addressed in procedures:
o Project interface o
Discrepancy and open item management o
DBD development (Writer's Guide) o DBDreview/ approval o
DBD maintenance / revision 20 4
i.
i
,H.
SCOPE / PLANNING / SCHEDULING i
A design basis program should begin with the development and approval of a project plan.
This document should have the " buy in" of all interested and affected parties. The project plan serves as a tool to communicate the scope and purpose for the development of the design basis documents.
The project plan should typically address the following:
r o
Scope / Objectives o
Planning / Approach o
Project Organization / Interface o
Schedule o
Budget o
Orientation Scope /0bjectives The program should be initiated by establishing the scope of the DBD project.
Without a clear definition of scope, there will be a tendency for non-project related activities / tasks to creep into the project, thereby blurring the focus of the project and causing undue budget overruns and schedule slippagais.
The scope definition should generally address the following:
o goals and objectives for the effort; o
limits of the effort; and o
establishment of responsibilities once the effort is completed.
Planning / Approach l
Having established a clear definition of project scope the next step is to initiate detailed planning. One of the first steps involves an assessment of the current status of existing design documents. The status of existing documentation can be a large factor in determining the level of effort required to review, collate and develop DBDs.
Prior to the establishment of short and long-term plans, an assessment of the plant document status should 21
\\
l
.w
~
n
---~,,-,o n
w-r-a
p l
be made. This assessment of design documents typically should involve the I
following:
I o
location of design documents (A/E, NSSS, utility, etc.)
[
o availability of des 11n documents o
control of design documents I
o consistency of information among design documents Sign' ant differences between the desired and actual condition of design documentation need to be identified ard considered during the planning and development stages of the effort. Decisions are required concerning the treatment of proprietary information.
For example, the need for detailed specifications or actual calculations on all equipment versus calculation summaries on selected systems and components should be evaluated and negotiated with the NSSS supplier and A/E.
The..ility should decide the best approach to accomplishing the objectives of the effort during the planning ehase. Management controls related to DBD development, discrepancy resolution, DBD validation, user needs for the DBDs, and information management systems needed to control and process information are examples of activities that must be considered in the planning of the effort. The pilot phase of the project should prove to be beneficial in establishing the approach for accomplishing the overall effort.
1 In making the determination of the level of review required for the design basis effort, consideration should be given to the following:
o status of original design and construction documents o
importance to plant safety and relikbility o
extent or frequency of post-construction changes o
effectiveness of the plant modification control program o
deficiencies and/or conflicts identified in using design documents After the completion of the pilot phase, the " lessons learned" should be incorporated via revision to the current project plan.
Decisions regarding 22 v
,the project budget, scope, objectives, organization, and various other activities should be revisited as necessary to make appropriate adjustments and fine tuning. As the project progresses, readjustr its should be made as necessary to address recurrent problems or adverse tiands.
Project Organization / Interface The project plan must address the need for a strong project organization and a streamlined interface.
At a minimum the project plan should address the following:
l o
identification of the lead organization for the effort o
identification of the participating organizations involved o
identification of key interfaces and communication methods o
identification of responsibilities including review and approval Schedule A two tiered scheduling approach is effective; one tier covering the overall effort, and the other tier covering specific activities.
Initially a pilot phase schedule should be developed with a gross schedule for the overall project.
Subsequent to the completion of the Pilot Phase the overall project schedule will need to be refined and finalized for the production of all DBDs identified. An overall project schedule of several years or more is common.
I The DBD development schedule should be integrated with the master schedule for other utility activities, including planned plant modifications and outages.
This may result in a schedule that would be mutually cost effective for both the DBD project and plant modification activities.
Additionally, the schedule may also be coordinated with the conduct of internal system assessments which would minimize redundant efforts.
Budget Initially a pilot phase budget should be dev+10 ped with a gross budget for the l
overall project.
Subsequent to the completion of the pilot phase the overall i
project budget should be refined and finalized for the overall project.
i23 l
. - ~, - - -
w w
+
-r-er-
,-w, ne-.
n a
+g-
@i elm
r
,The budget may also consider funding for discrepancy resolution, validation of.
DBDs, along with maintenance and control of DBDs.
Orientation l
The project plan should provide for adequate orientation of the project team.
l The orientation plan should also include consideration for the needs of the users of design basis documents.
Initial orientation also will provide senior utility managers an opportunity to emphasize the importance of the effort, why it is necessary, and the necessity for accurate results.
Line management involvement in this effort will enhance the results for a better project and suosequent use of design basis documents by the end users.
Typical orientation plans should include consideration of the following items:
o Project plan and project procedures - program overview o
Availability, access and use of utility data base systems o
Effective writing o
Format and content of design basis documents o
NSSS/AE orientation to utility procedures for contracted work o
Use of developed DBDs o
Requirements of proprietary and safeguards information o
Maintenance of the DBD during the development phase o
Requirements for handling controlled documents o
identification and handling of discrepancies o
Reorientation of personnel due to turnover or attrition on long term projecte l
24
l
,V.
ADDRESSING DISCREPANCIES l
A.
INTRODUCTION I
l This section provides a systematic, comprehensive approach to address discrepancies identified during the implementation of design basis programs.
This approach includes methodology to assess the safety significance of discrepancies, evaluates significant discrepancies for both operability and l
reportability issues and providen prioritization criteria to assist in the l
final disposition of each discrepancy.
This section also clarifies reportability determinations, and offers a reasonable method to communicate 4
significant findings to the NRC. Additionally, a final evaluation is included following the completion of a design basis program activity that reviews the discrepancies identified for any incremental or cumulative effects.
The process described in this section may *.e adapted to existing utility processes that address non conformances or may be utilized as a stand alone process.
The objective of this section is to provide a managed approach to resolving discrepancies that promotes diligent self-initiated utility efforts toward the aggressive implementation of design basis programs that ultimately enhance safe, reliable plant operation.
af B.
OVERVIEW The implementation of a design basis program will identify open items which may include questions, concerns, and cases of missing information.
Industry experience indicates that the majority of these open items have little or no safety significance and are routinely dispositioned in accordance with a utility's standard work practices. Those open items that are confirmed discrepant and may have potential safety significance are considered discrepancies, and their treatment is the subject of the guidance contained in this section.
l l
A flow chart depicting a process for addressing discrepancies is provided in Figure 2.
The process is generally consistent with normal utility practices 25
n:
l
,for toesting non conforming conditions identified during the course uf day-to day plant activities. The process applies to individual design basis program activities (e.g., system DBD efforts) that have a defined scope and timetable.
Following the identification of a discrepancy, a screening element is applied to quickly determine its safety significance.
If the discrepancy does not i
raise a safety concern based on the results of the screen, it can continue to be evaluated and dispositioned and, pending completion of the particular design basis activity, would be subject to supplemental review during the final evaluation.
If the discrepancy is determined to be safety significant, it would undergo both operability and reportability evaluations.
The screening element should be completed in a timeframe commensurate with the apparent safety significance Lf the discrepancy.
The operability evaluation would determine if an operability issue is posed by the discrepancy. An underlying premise throughout this element is a presumption of operability, in cases where broad engineering experience and judgement indicate the affected system or component to be functional, but where inadequate information is available from which to make and fully document a final decision, the presumption of operability would apply.
The conclusive information should be pursued expeditiously.
If an operability i
I issue is identified, the utility would take the applicable Technical Specification action or other appropriate action deemed necessary to maintain the plant in a safe condition.
If no operability issue is identified, the discrepancy can continue to be evaluated and dispositioned and, pending completion of the particular design basis activity, would be subject to supplemental review during the final evaluation.
The reportability evaluation ensures timely reporting and regulatory compliance.
If a reportable event is identified under the existing regulatory requirements, the utility would report the event to the NRC..If reportability is not required, the discrepancy would be subject to supplemental review during the final evaluation. The reportability evaluation should be completed in accordance with current regulatory requirements.
26
~
The final evaluation determines whether the discrepancies have any incremental or cumulative effects that would result in subsequent operability issues or reportable. vents. Additionally, the discrepancies are prioritized based on their relative safety significance, and their final dispositions are determined in light of the information collated by the particular activity.
The closecut element assures that the disposition of each discrepancy is satisfactorily implemented.
)
27
l l
i l
L Discrepancy FIGURE 2 oeierminadon Design Basis Discrepancy I
Safety N
Resolution Process Concem?
I i
t-i l
W Y
ReportabWly l
Evahmiinn Evaluation m
a f
i i
N N
i operabliity Repwishiny l
issue?
issue?
6 Y
Y 2 r i r yr w
TakeTech spec compiece Report orotheracdon DB AcWwity l
to NRC E
i l
N Ev & m n l
i 4
I ck=eout l i
1
V
,C.
.INDIVIOUAL ELEMENT DESCRIPT!DNS The following disciission elaborates on the-individual elements that fm the discrepancy resolution process.
Discrepancy Determination Many questions, concerns, cases of missing information and potential discrepancies may be raised or identified during the course of a design basis activity.
Each utility must assure that such open items are being diligently addres:ed through the work process at a reasonable pace, consistent with good management practice and the level cf potential safety significance, toward ultimate determination as to whether a discrepancy truly exists.. When an open item is confirmed to be discrepant and raises a. potential safety concern, it should be forwarded to the discre, nancy resolution process. expeditiously, i
Those open items that are not confirmed as discrepancies or that do not have a
any potential safety significance should not be forwarded to the process.
Applying the same level of review to each and every open item would quickly overload the process and result in ineffective use of valuable engineering resources.
The remaining open items (those not confirmed discrepant or not potentially safety significant) should be resolved in'a manner consistent with the utility's standard work practices.
Screen for Safety Significance Once a discrepancy enters the procu
, a method is needed to quickly screen each item to determine the safety significance (existence of safety concerns) or impact to the continued safe operation of the plant. Without this determination, the process could easily become excessively burdened.by giving equal priority to items of little or no significance. The following questions provide a suggested screening method to initially determine the safety significance of each discrepancy:
(1)
Does the discrepancy appear to adversely impact a system or-component explicitly listed in the Technical Specifications?
29 f
= _.
n
.(2)
Does the discrepa9cy appear to compromise the capability of a system or comportir to perform as described in the Safety Analysis-Report?
l (3)
Does the discrepancy appear to adversely. impact any applicable licensing commitments?
If the answer to any of the above questions is yes, operability and reportability evaluations should be initiated expeditiously.
Consideration-should be given to informally advising the NRC' resident inspector or appropriate regional NRC personnel if a significant discrepancy has been identified through the screening process, and that operability and reportability evaluations will be commencing.
(This does not preclude immediate notification' requirements under 10CFR50.72, if applicable.)
Communication with NRC at this point in the process can be~an effective means of esi Alishing support for the managed approach to the process.
If noie of the above questions are answered yes,-the discrepancy may continue to be' evaluated and dispositioned and, pending completion of the ' design basss activity, would be subject to supplemental review during the fin 0 euluation.
Operability Evaluation An underlying premise throughout this element is a presumption of operability.
Recognizing that a primary objective for initiating a design basis program is to enhance the information on which operability determinations are based, the presumption'of operability is intended to apply when broei engineering _
1 experience and judgement indicate thSt an affected system or component is functional, but where inadeounte information is available to make and fully document the final decision on a particular discrepancy.
The necessary information should be obtained or developed on a priority. basis and should be acted upon thereafter. tie presumption of operability servesito reduce potential disincentives to the aggressive performance of the "rogram activity.
This approach also satisfies the need to operate the plant conservatively by
. limiting the potential for unnecessary challenges to plant safety systems and L
personnel.
l 30 i
\\<
~
Il _,,
-.m.
. -., ~ -
-,e~...
. +.....
.r..
4 -y~.,--.
l.
,The operability evaluation should be consistent with normal utility practices that address non-conforming conditions discovered during the course of routine plant activities.
If the evaluation determines that the discrepancy results in an operability issue (i.e., the impact of the discrepancy is such that action needs to be taken to place the plant in a safe condition), the process would proceed to the " Actions" element.
If the evaluation determines that the discrepancy does not result in an operability issue, the b,. sis for that conclusion should be documented, and the discrepancy may. continue to be evaluated and, pending completion of the design basis activity, would be subject to supplemental review during the final evaluation.
The presumption of operability is not intended as a means of deferring necessary actions to address a discrepancy.
If a discrepancy clearly impacts the safe operation of the plant, action to place the plant in a sa'e condition should be taken. When an operability issue has been determined through the evaluation, actions must be taken expeditiously to maintain the plant in a safe condition.
The concept of a presumption of operability acknowledges that in certain cases, broad engineering experience and judgement can allow Le pursuit of conclusive information to make and fully document a final operability decision.
This may preclude potential plant transients and shutdowns caused by actions based on inadequate information that unnecessarily challenge safety systems and plant personnel.
Take Technical Specification Action or other Appropriate Action When an operability issue is identified for a discrepancy based on the preceding operability evaluation, appropriate action should be taken to place the plant in a safe condition. The action should be consistent with normal I
utility practice.
Reportability Evaluation In order to assure conformity to existing rsgulations and to keep the NRC informed in a timely manner, each discrepancy identified by the screening element must receive a reportability evaluation.
Current regulations 10CFR50.72 and 73 contain requirements for immediate notification and Licensee Event Reports (LERs) respectively.
The particular part of these regulations 31 em
'M,e V
r' m-er-e-
M
=m
- 'N--w--e 1
-e*-w-g-m-4-vm-ee-w-
- r" that has been the subject of much discussion and confusion is the interpretation of what constitutes a condition "outside the design basis of i
j the plant." This confusion stems from differences of opinion on what
=
l documents or information constitute a plant's design bases.
l Design bases as defined in 10CFR50.2 include information that identifies the specific functions to be performed by a structure, system or component, and the specific values or range of val'.;as chosen for controlling parameters as reference bounds for design. Applying this definition to determine what is "outside the design basis" results in the following:
(1)
A condition where a strur.ture, system, or component 1; uneble to perform its intended safety function (s), or (2)
A condition where a structure, system or component'is beyond the specific value or range of values that were chosen for controlling-parameters as its reference bounds for design.
These two conditions serve to clarify what "outside the design basis" means with respect to the regulatory requirements noted above. When a discrepancy is evaluated for reportability, the presence of either of these conditions could constitute a reportable event.
These conditions would seem relatively easy to detect when a plant's design bases are clearly understood and documented. However in many cases elements of the design bases are either unknown, not documented, or unclear, and the determination of a discrepancy's reportability is difficult.
In these cases, it is reasonable to use an approach similar to the " presumption of-operability" discussed ea-lier. One need not-automatically assume that a condition "outside the design basis" exists. When the information necessary to make a final decision is developed or obtained, the reportability decision should be made expeditiously.. Industry experience has shown that information is often identified during the course of a design basis program activity that cortributes to the resolution of a previously identified discrepancy.
In this process, the element entitled " Complete DB Program Activity" is included so as 32 i
m-
.m--e wi e,.w9...-p w
m
,,g-,..,
,-y--+3,,,3 ep..g y
,_s
, y9
- l 1'.
,to allow relevant information to come tb the fore, and is followed by a final evaluation where a discrepancy can be reevaluated for both operability and reportability.
J As noted in Section III, distinguishing the design basis information from the supporting design information also serves to facilitate the reportability evaluation.
Report to Nuclear Regulatory Cossiission (NRC)
When a discrepancy is determined reportable, a written LER shall be filed.
Should subsequent discrepancies identified 'during the design basis program result in additional reportable events, written supplements to the initial LER may be filed when the discrepancies are technically similar.
For example, a program activity to develop a Residual Heat. Removal (RHR) System DBD identifies that a functional requirement, such as closure on a conw:nment isolation signal, was not considered in the design basis of a motor operated valve (MOV). The case was considered reportable and an.LER was filea for the containment isolation deficiency,' not as a RHR system deficiency.
A o'equent program activity to develop a Containment Spray System DBD l
identifies that closure on a containment isolation signal was not considered j.
in the design basis of another MOV.
In this case, a supplement'to the initial LER may be filed rather than a "new" LER.
Portions of an initial LER (e.g., inng term corrective action,' final assessment of safety significance, root cause) may be~ deferred until the specific program activity (e.g., RHR' System DBD) is completed.. hen portions W
are deferred, a clear schedule for meeting all 10CFR50.73 requirements should be provided to the NRC.
Following completion of the activity, the final evaluation should comprehensively review the identified discrepancies. At that point, a supplement to the LER, if.necessary, should be submitted that addresses the deferred areas of prior filings and fulfills the pertinent regulatory requirements.
The above guidance clearly reflects the managed approach to addressing discrepancies during the implementation of design basis programs.
An 33' S
- .--.4
-~,
,.-r.-..
.- <,... ~, - - - - -
~,.
--e.
-m.-,...
5 4
~
aggressive program may identify a number of potential findings, and the LER process could quickly degenerate into a proliferation of submittals and revisions.
For example, it makes little sense to prepose long term corrective action in the first LER when subsequent findings may impact the decision regarding the appropriate corrective action.
This would detract utility resources with-no safety benefit.
This approach balances the need for prompt reporting to the NRC with a Jructured method that efficently addresses discrepancies both individually and collectively.
This methed offers several advantages. Olscrepancies identified during an activity such as the development of a system design basis docunient may be closely related and-should be reviewed for cumulative impact on the system's function (s). Any supplemental LERs should convey the results of further engineering analysis and review of the impact of the discrepancy.
For this reason, certain issues or problems that are technically similar may be reported in one LER and subsequently supplemented or revised as the overall impact is understood. Additionally, this approach provides timely reporting when individual discrepancy reportability determinations are made and offers a sound rationale for combining LERs when appropriate.
In summary, safety l
oenefits would be attained through the comprehensive evaluation performed at the completion of the activity, while potential disincentives to the aggressive implementation of.the program would be reduced.
Complete Design Basis Program Activity The main purpose of this element is to allow all relevant'information pursuant to the activity to be available for use in the subsequent " Final Evaluation" element.
l As noted previously, industry experience has shown that a discrepancy can often be resolved by information identified later in the related activity.
Thus, it may be premature to completely disposition an item without allowing all pertinent information to come to the fore. Additionally, by performing a final evaluation when the activity is completed, the cumulative effects of the discrepancies may be addressed in a more comprehensive manner.
34 m
-m,,
,,y, ye,,
y--.,.
,,,-y
,-ww.e
-se,--
--w-y,,
q
r Final Evaluations At this point, the design basis program activity has been completed and the discrepancies associated with the activity have been assessed, and those that were screened as safety significant have been evaluated individually for both operability and reportability issues.
This element allows the tie in of applicable information gathered during the activity and applies it toward the-comprehensive review of the discrepancies.
There are three main objectives associated with this important element.
The first is to look at the discrepancies in total and determine if there are any cumulative effects that impact operability. The second is to review the discrepancies in total with respect to reportability. The third objective is to both prioritize and finalize the dispositien of the discrepancies.
If a discripancy had previously resulted in an operability issue, the. actions taken should now be reviewed in light of any additional discrepancies or new ir. formation identified during the activity.
The other important aspect of this particular evaluation is to determine if there are any cumulative effects associated with the discrepancies.
It is possible that several discrepancies, when reviewed individually, did not result in any significant concerns or issues, but that together may impact the ability of a system or component to perform its intended function (s),
if an operability issue is determined as a l
result of t! '; comprehensive evaluation, then Technical Specification action, if applica.da, or other appropriate actions should be taken.
The final evaluation for reportability should assess the cumulative impact of discrepancies on reportability determinations.
It should determine if any conditions result that may be reportable under existing regulations.
In addition, if any reportable events were concluded from the individual evaluations, a final supplement to the initial LEF! may be filed that fulfills any remaining 10CFR50.73 requirements and provides updates to corrective action plans based on the new information identified.
The final task within this element is to priorne and disposition the remaining discrepancies that have passed ihn ugh the process. The prioritization is-important in that it distinguiMs those ii. ems requiring 35-
s
(
~
more ihimediate corrective action from those that may be resolved through routine scheduling practices and from those that may not require any action.
l
~
l Several utilities have developed methods to prioritize discrepancies.
Some have used probabilistic risk assessments (PRAs) for this application.
Others simply route the discrepancy for disposition to the appropriate engineering discipline through the routine process for addressing non-conformances, while others have employed a review committee to determine the priority of an item.
All these options may be appropriate based on an individual utility's functional organization.
Application of prioritization criteria may be dependent on the specific nature of the discrepancy.
It is important to use broad engineering experience and judgement that takes into account the circumstances surrounding a particular item.
The following suggested criteria offer a methodology to prioritize discrepancies based on general safety considerations and should be applied together with engineering experience and judgement:
(1)
Does the discrepancy potentially impact the operability of a-system or component that provides or supports a safety function?
(2)
Does the discrepancy question the validity or completeness of a design change undertaken on a system or component?-
(3)
Is resolution of the discrepancy necessary to support a' future design change planned for a system or component?
(4)
Would resolution of the discrepancy facilitate operability determinations on systems or components that have proven difficult based on past operating history?
If the answer to questions (1) or (2) is yes, then resolution of the discrepancy should be pursued as a near term action item with a completion schedule comensurate with the safety significance.
If the an:wer to questions (3) or (4) is yes, then resolution should be pursued as a long term 36 y
, -... +,. - -.... - -.. _ ~..
~
.,.m
+
- _ - ~ - - - _____.
i.
pction' item.
If none of the questions are answered yes, then the discrepancies are considered non-priority items that should be pursued consistent with the utility's management guidance.
Industry experience has shown that a large number of discrepancies discovered-during design basis program activities are related to missing information.;: A.
main premise of the prioritization criteria is_ to determine whether there is a substantive reason or need that calls for pursuing the resolution of an item i
as a priority. With respect to missing.information, this means that the-reconstitution of design documents need not be pursued when an established need does not exist. Additionally, reconstitution ray not be necessary when other sources of data (e.g., test results, operating history, related ' industry experience) can provide reasonable assurance of conttrued safe operation.
It is recommended, however, that r ;
ord be kept th>t ideMi fies an area where-there is a lack of design docu.aw.. lon to a biu iruitless patential searches for this information in the future..
Closecut l
Once the disposition of each discrepancy is complete, the closecut element should effectively track the item to its successful resolution. -The accountabilities and responsibilities of each plant / engineering organizational unit associated with the implementation of the disposition should be clearly understood.
The element shouid ensure that the corrective actions taken adequately address the discrepancy and should preclude repetition of'any condition adverse to quality. This may. Include training, education, and j
programmatic reforms as applicable.
The closeout of-a discrepancy should be-documented appropriately.
l 37
~
_.~, _. _ _ _ _.. _..
w wa-,.
~
sv s.,
.s..
- ,g.
.gumen, y,e -s
.mm,c u
w.,
g g_,
.,,,,. +,, +,,
.n, u
w,,
re i
s i
e 8
e 4
9 e
a
'?
Y 4
l C
I
,k
['
38 i
.f e w w
yw-voy--m3+w v yM q-gg
_,ib mu--
g-9-*
pwg---wgoww4-
=+g,ye
- - q g
rowww a
Mr-we u--=
TrerTev ysN--w*er._,,,py
,9 e-
-z i
4, p.7 i
9 0
C 6
3 h
,5(
i
-P h
3
- I' f
l I
r
.r-e I;
w 1
1 I
I P
7 f-Y
- [b l"
t
-(
r f.
y u
1r t
i h
i 1
h I
I
'tt J
m -.;, n -- -
- -, ~ _ n. - _,.., -
. ~ - +
- ~.
Appendix B Examples of Design Basis Information NOTE: This information should be used with appropriate-input from the design authority.
LOW-PRESSURE CORE SPRAY (LPCS) SYSTEM FUNCTIONS:
Provide emergency core cooling at low reactor vessel pressures to mitigate the effects of large pipe breaks.
VALUES OF ' CONTROLLING PARAMETERS USED AS REFERENCE BOUNDS FOR DESIGN 1.
Fuel cladding temperatures shall be maintained at or below 2200 degrees tahrenheit.
(10CFR50.46(b)(1) p. 476) r 2.
Total oxidation of the cladding shall be limited to 17% of the original cladding thickness.
(10CFR50.46(b)(2) pp. 476 477) 3.
Hydrogen generation shall be limited to 1% of the amount that would be generated by compl**' oxidation of all metal inithe cladding.
(10CFR50.46(b)(3) p. 477)
(
4.
A coolable reactor core geometry shall be maintained.
(10CFR50.46(b)(4) p. 477) 5.
The core temperaturo shall'txt maintained within acceptable limits during the long-term post-LOCA cooling phase.
(10CFR50.46(b)(5) p. 477) 6.
Parameters used to bound LPCS capability to meet the above criteria:
a)
Core thermal power:
105% of rated steam flow b)
Vessel steam dome pressure:
1055 psia c)
LPCS system at rated flow i
d)
Vessel pressure at which LPCS flow starts:
289 psia 45 k
,,....-,.4
.~.,.,...._.,, -..
i R i w)
Assumed pipe break is a double-ended rupture of one reactor recirculation system suction pipe.
ADDITIONAL DESIGN CONSIDERATIONS 1.
The LPCS is classified as Seismic Class I and shall be designed to meet the structural requirements of this classification. (GDC 2, RG !.29) 2.
The LPCS shall be designed so as to maintain the integrity of the reactor vessel and primary containment during and after a design basis event. (GDC 14, 16) 3.
The LPCS is designated a Quality Class 1 system:
its design, fabrication, erection, testing, operation, and maintenance shall be performed according to Quality Class 1 standards. (RG 1.26) 4, The LPCS shall be designed, operated and maintained such that it can perform its function continuously in a harsh environment for 4320 hours0.05 days <br />1.2 hours <br />0.00714 weeks <br />0.00164 months <br /> following a design basis accident. (GDC 4, RG 1.89, NUREG 0588) 5.
The LPCS shall be designed, operated and maintained such that.the system can perform its function continuously for 4320 hours0.05 days <br />1.2 hours <br />0.00714 weeks <br />0.00164 months <br /> following an earthquake up to the safe shutdown earthquake, which may or may not coincide with a design basis accident. (GDC i RG1.29) 6.
The LPCS.shall be designed to ensure its protection from overpressure conditions or to ensure tha; it can withstand maximum expected overpressure conditions. (RG 1.26, ASME Section III, subsection NC) 7.
The LPCS shall be designed to limit the effects of LPCS pipe breaks on 3
other plant systems, structures or components. (BTP ASB. 3-1, ME8 3-1) 8 The LPCS shall be protected from the effects of internally _ generated missiles. (GDC 4, RG 1.115)
\\
46 J
Appendix C Examples of Sources of Supporting Design Information t
o Engineering evaluations, practices, procedures, and instructions-l 0
Computer codes used for design or design analysis o
Design baseline analyses and calculat.:.ns to establish effects of postulated accidents, including:
l transient analysis seismic site-specific criteria
(
flooding site-specific criteria o
Calculations or analyses that verify that the restraints imposed by the design bases have not been exceeded, including:
component classification evaluations j
load sequencing.and electrical supply sizing calculations setpoint calculations and methodologies-equipment sizing calculations motor-operated valve calculations, _ analyses, or. test results' that establish switch tolerances / settings Reports and engineering studies that verify that the-restraints imposed-o by the design bases.have not been exceeded, including:
equipment qualification fire protection safe shutdown capability assessment relay prctection coordination studies o
Personnel involved or familiar with the original design activities o ~
Correspondence, meeting minutes, and other documents pertaining to the original design 47 i
+-w a
- -v s
-,v,-
,e,,
w--
.e-
~--- ---,-.
e
,-v w
-ew-
m....,
_ _ _,. _ _ _.m, r
h S
e e
f_
e 9
C i
f I.
(
f f
l W
t t
1 i
I k
f I-l I
k e
t 4
48 9
.t fs ea m
',w/ 7 4 ms 2,re+-
aiV w
wr' cv
- r., a-n c ur,n W
d ihrnw%ha i Wi GPhO'NN 4WMM"4h W*"Y'M " bT N 6
p.
\\
Appendix 0 Examples of Supporting Design-Information NOTE: This information should be used with appropriate input'from the design authority.
Supporting design information provides the rationale for design basis functional requirements and values or ranges of values for controlling parameters. This information can be collated on a structure, system, or component level.
However, it should be recognized that component level design bases are often derived from the system level design bases.
The following are examples of supporting design information:
System level Information Design Basis Reqt.* *ement - LPCS injection flow starts.at vessel pressure o
of 289 psia.
Supporting Rationale - 289 psia is the difference between the drywell atmosphere and react - at the time of LPCS injection assumed in the LOCA analysis.
(ref. aa) l l
Design Basis Requirement - CSS must maintain a minimum post-accident o
sump pH of 8.5.
Supporting Rationale - A pH of 8.5 is specified to assure iodine retention in solution.
(ref. xy)
Design Basis Requirement - High pressure injection flow must reach the o
[
reactor vessel within 2r seconds after ESAS signal.
Supporting Rationale - 25'secnnds ~is-the desired response. time to mitigate a small break LOCA. Note: The smal1~ break LOCA analyses assumed a 35 second response time for conservatism.
(ref. pq) l 49
I j
o Design Basis Requirement.- The AFW suction header shall be a minimum of 12 inches in diameter.
Supporting Rationale - The suction header must be capable of supplying l
1950 gpm and provide adequate NPSH with three AFW pumps running simultaneously, one in runout..The CST is at minimum level and maximum temperature for this flow rate. (ref. gh)
Component Level Information o
Design Basis Requirement - Motor Operated Valve XYZ must open in ten seconds at I psid and 80% of rated voltage.
Supporting Rationale - Ten seconds is desired in order to meet the 1
system response time requirement of high pressure injection within~25 seconds at design basis conditions. (ref. mn).
o Design Basis Requirement - Relief Valve ABC pressurm setting of 165 psig and flow rate of I gpm.
Supporting Rationale - Parameters must meet ASME Section III, Section 7000 code requirements.
Per code,: pressure. setting equals piping design pressure (ref, ef).. Flow rate must.be sufficient to prevent a pressure greater than 110% of the design pressure due:to thermal expansion and-l leakage through the reactor vessel. isolation valves. (ref. gh) o Design Basis Requirement - Miniflow bypassLvalve XYZ must open in four seconds.
Supporting Rationale - Four seconds is the desired opening time. The valve should be designed to open'as fast as practical to minimize the time that the pump operates d<sadheaded. Valvet and bypass piping are specified as 4 inch to pass pump miniflow requirement (ref. st).
Past extarience had' demonstrated that vendors can supply fast opening valves 50 e
t
}
.,~,,
.- a
. - -.,i...-
--c r
-r w
e.--
e,.f-
~-e-r-n s +w m
-e--c--=w.e-2 wr---+-*
I J
e
' with stem stroke rates of one inch per ser'Ad.. Hence, a four second l
t stroke time for this four jugh valve war selected.
(NOTO ref. pq j
indicates that up to eight. $scords is inloweble.)
j o
Design Basis Requirement - Reset relay for Alternate Rod Insertion system set for 4'5 2 seconds.
l
-Supporting Rationale - Minimum reset time of 40 seconds is established.
by accident analysis to ensure all rods are inserted prior to reset, f
(ref kl) A maximum of.50 seconds is suggested-to ensure reset is accomplished within a reasonable time, but it has no specific engineering significance.
l Design Basis Requirement - AFW turbine feed pump. governor is set' 4100. to o
4200 rpm.
Supporting Rationale - The 4100 rpm is established to ensure sufficient S/G feed flow with the maximum RCS pressure, maximum flow losses for. the piping configuration, maximum recirculation flow of 15 gpm.. and minimum NPSH. The 4200 rpm is set to prevent overpressurization of the discharge piping at maximum suction pressure and minimum flow conditions. _(ref.xy)
Structure level Information -
s Design Basis Requirement - Lateral load resisting system elements must o
be designed to withstand 100 mph wind pressures.
Supporting Rationale - The lateral-load resisting system provides stability to the structure under wind loading.. A 100 mph wind velocity was selected in accordance with ANSI AS8.1 based on a review of the geographical location of the structure.
(ref,bc) 51
- -... -. ~
-m M.
6,,-^"
T^^-
r es
}'.
M
_,Ap3p m=..
C e
.4 e
r 9
e i
i
)
e
?
I i.
?
w I
l I
I r
)
t v
w i
l l
l l?'
52
.)
+wb**wmkhd e-mem-%n,e-A
io Appendix E Potential DB0 Applications '
ENGINEERING o
Conceptual design development and alternative considerations o
Design specification for in-house or contractor designers and for inter-discipline coordination o
Calculations and analyses J
o Bases for technical reviews, safety reviews, and 10CFR50.59 safety evaluations o
Independent design verification o
Procurement specifications i.
l o
. Identification of information and documents affected by change o
Installation specifications Installation and functional testing requirements and acceptance o
criteria o
Field change request evaluations Evaluations of operational evm.ts and non-conforming conditions o
Justifications for continued operation (JCOs) o o
Selection and. review of equipment performance surveillance data o
Bases for operations, maintenance, and surveillance procedures review 53 1
. +. -.. -,.
4.
..-4.
o Evaluation of material substitution, spare parts equivalency..
and material upgrades OPERATIONS o
Abnormal event assessments 1
o Riportability determinations r
o Sases for unusual system alignment (e.g., for maintenance or.
testing) assessments o
Temporary modifications reviews o
Selection and review of component and system performance data o
Addressing non-proceduralized events o
Operator aids and training material development o
Operations procedures preparation and review NAINTENANCE o
Post-maintenance test requirements and acceptance criteria o
Procedure and work instruction preparation and rcview-o Assessment of material-condition requirements LICENSING o
Licensing analyses (e.g., Updated Safety Analysis Report) o Technical specifications' review and changes 54 q
l
,o
' License amendments i
o Reportability determinations TRAINING o
Bases for lesson plans and trainiag materie.ls o
Simulator fidelity-OTHER o
Performing technical audits f
o Determining recommendations for reducing personnel doses o
Safety System Functional Inspections o
Probabilistic Risk Assessments o
Margin Management o
Setpoint Selection
{
1 t
~.'
55 li
.j, i,
p.,tm-44'
% qms; wnemAC.N2 r29 5gre--,W-A, ray + t,Lvv -, -
we-A o.JAs,t -
A M-M r
.g
- -Q%' u nx,IE%MMtMA,,Lt ?U
- tQ44%
W-.Q&
__W';
tGB X Js; a
_K.
J.-
Rwg)
A Ql, k,/-h y
i e
- p $
-t i
e 0
0 4
t 1:
P 2
b b
b.
Y r
k t
h i
y' Y
L i.
r
. j
~ f 1
i '
1 s
l l
56-
\\
4 iL
- ar.
we n
,i.
0 e
Appendix F Other Types of Information to Consider for DBDs This appendix is a compendium of other types of information that may be collated iito DBDs.
The types of information included in the DBD should be I
directly related to specific user needs in support of the overall program objectives.
j o
System Descriptions - A narrative discussion of the system configuration, system boundaries (highlighted drawings such as P& ids, etc.), functional and operational requirements for all plant modes and operating conditions.
This information is generally obtained from:
o NSSS supplier and A/E' system descriptions,
-I o
original design interface documents, o
UFSAR, and o
system design specifications, drawings and calculations..
Regulatory requirements - A listing of applicable 10CFR50 Appendix A, o
General Design Criteria, and other regulatory requirements, and-discussions of applicable accident -scenarios that require the system to operate and the operational requirements that must be met.
Codes and Standards - Identification of the original' bases codes and o
standards (including year and addenda) adopted that specifically apply l
to the DBD as a whole, Functional Process Requirements'- A listing or narrative description of -
o the system process requirements. This may include the following:
system flows, pressures, and/or heat loads, l-L special system design considerations such as net positive suction head requirements, 57 1
PT-plant transients and accidents the system. supports and how the availability of the system is-ensured,.
a brief description of environmental limitations:on system operation, such as normal radiation. fields and possible post 1
accident conditions and key instrumentation and control requirements to provide remote shutdown capability and enable local monitoring:of process activities.
The information to-support this section could be obtained from the system calculations, UFSAR, system interface ' specifications, the plant accident analyses, or the original? NSSS supplier and A/E design engineer's file.
In addition, some information could be obtained from q
the specialized plant hazards analyses, such as the fire hazards analysis, high energy line break analysis, and the harsh environment
- analysis, l
System Interfaces - A listing'or narrative descriptioni of ot'her-o interfacing systems that are required for'the subject system to perform its function.
The information to support this section could be'obtained from system-calculations, mechanical and electrical drawings,. and system -
specifications.
Frequently, calculations such as the electrical _ loading calculations or the instrument air system design calculations' identify the specific system interfaces for t'hese systems and provide information to support development' of this section, o
System Interlocks - Descriptive information on interlocks with-interfacing systems, the logic at the interlock, bases of interlock and reference to logic diagram.
1
[
Xm L
i -
,o
- System Performance Requirements - Description ~of the safety related and non-safety related performance requirements and.why they are required, for the system and the as built system configuration which satisfies each requirement.
l o
Structural Requirements - Discussion of the requirements for seismic, wind, thermal, water and any other static and dynamic load conditions (including accidents),-stress, shock and reaction forces.
Equipment foundations and major components (e.g., tanks, pumps, heat exchangers, ducts, duct supports) may be discussed, o
Separation / Redundancy / Diversity Requirements - Specific requirements which apply to the system.
i f
o External Hazards - Discussion of the applicability of certain external hazards to the system could be addressed in Topical DBDs, such as Environmental Qualification Requirements', Seismic Requirements, Fire Protection Requirements, and Environmental Protection. Requirements-(e.g., Flooding Protection, Missile Protection, Tornado Protection, Pipe Whip and Jet Impact Protection)
Special Material or System Chemistry Considerations -' Discussion of any o
special materials used in the system'or components'and the basis for i
material selection. Any materials which are prohibited from use in j
components / systems shall be stipulated. - In addition, any.'special' system chemistry considerations could be defined.and discussed in this section.
Inservice Inspection Requirements?-: Discussion =of Inservice. Inspection-o (ISI) and Inservice Testing-(IST)'astrequired by Section XI of the'ASME Code. These-requirements could be. summarized and the proceduresithat-implement the specific ISI and IST requirements could-be listed or referenced.
Component Design Bases Requirements;- Unique component level design -
o basis requirements and assumptions such as capacity, reliability,
- 59 l
1
n 4
' seismic and environmental requirements, codes and standards.
Discussion -
could include the following:
3 l
a description of each major component, l
a discussion of operating modes and the role of the component in the system, and a discussion of how the installed component configuration satisfies the system design basis requirements..
The information in this section could be presented in the form of criteria statements with tables and graphs used~ to specify operating limits.
The information to support this section could be obtained from the procurement specifications, the original design engineer's file, vendor manuals, startup test data, and/or system, calculations.
o Postulated Failures - Description of failure modes considered in the-system design.
It could include passive failures, such as pipe breaks,-
and active failures, such as failure of a valve-to close or a pump to start on demand. A discussion of the impacts of a postulated support system failure, such as a valve vepositioning on aLloss of instrument air, could also be included.
Information -to support the developednt of this section could be obtained' from the SAR accident analyses, the regulatory Safety Evaluation Reports i
for the plant, system design' drawings and component. specifications, and system tests.
In addition, plant events may require'special tests or analyses that can be used as inputs to this.section, i
Testing and Testability Requirements - Those unique' system testing o
raquirements which resulted in special system design features.
60 1
~ ~ -. -..
L I
- The information to support the development of this_section could be obtained from the original system' design specifications, operating ~
experience with similar equipment (such as turbine trip testing capability), startup testing requirements, Technical Specifications, I
surveillance testing requirements, and ISI requirements. Additionally, information could be obtained from correspondence that' denotes specific l
utility desires for system testing and performance monitoring capability.
o Operational Limitations and Precautions - Description of specific-operational requirements considered in the design, such as the following:
i special operational actions to be taken in the event of component. failures or unusual-operating conditions (such-as severe weather),
special system interlocks requirements, and key operational considerations for equipment and personnel protection.
The information to support the development of this section could be-i obtained from system and component design specifications, correspondence between the utility and the NSSS supplier or:A/E, and calculations that evaluate system performance under unusual operating conditions, such as tornados, droughts, or. extreme heat or cold.
Experience'has shown that much of the information for this section may need to be recreated, Change History - Description of the design change history. The change.
o history section'is either a narrative or~ a listing of changes to the system since the issuance of the plant operating license with an explanation of the need for each change.
The advantages of this 6fomation are as follows:
.61 i
{
..,...i,~..-. +
.: n
+.
,.n.
- pg.
provides a ready source of rationale for past. changes to systems, components, and structure,-
t aids the review process to ensure design. basis requirements are updated and des gn continuity is maintained, and 1
assists the process of root cause' determination of operational problems.
Margin - Description of' applicable margins. This ~section couldibe o
presented as a table that shows-the allowable parameter levels'and the expected parameter levels the system will experience during' operation.
It could be invaluable when evaluating operability concerns.
In addition, this section could be a key input to Jhe preparation of safety J
reviews, since this information clearly addresses the impact of changes on the margin of safety. However, this can be. a difficult section to-i
. develop in that system sensitivity analysesimay not have beenoperformed 1
which would enable identifying all component margins.' Identifying and documenting margins when specific. design basis information.is1being developed or as subsequent analyses are performed could be a valuable '
reference, i
o References - A listing of Lthe documents containing design bases.
information. These include d : wings, specifications, calculations, engineering,. correspondence, +.ndor &. regulatory) topical reports, vendor evaluations, engineering evaluations, engineering safety
- evaluations, and other data.
o Tables / Figures / Appendices.- Tables:and-figures.may be utilized 1to' list data. All. tables and figures 'should be. referenced to appropriate-section.
u is
\\
62 e
Mb d
a.
a e
a
-T m
,,.g e
y g,
g 7w.
p wt9,3.+..
p w
,i.
.o
' Miscellaneous Items The following-items should tut standard items considered for DBDJ:
o DBD Cover Sheet o
DBD Media (Hardcapy/ Computer discs) o List of effective pages o
Table of Contents o
List of Tables
~
o List'of Figures (including DBD boundary definition) 5 5
h i
63-1
--4
r
.1 I
e-e-
' F [
- e f
I 4
g 5
8 p
9 a
vv te l
t a
?m J
9 Y
k 7s t
??
t i
i I
ll' I
i a
};
\\J s
7 7.
f 3
I':
i 4
3 l-k' 1-V 64 L
l~
r
?'
s I
t
.Ao e v c4.m&#
w,mem, m.--~~.- ~ e m - *.- - --,, - ~2m,_.-u - A %. ~. ~.s m w.usm -c,,.r_r%2 %,,m-~ w e a _ A
. Enclosure 2
- p*Mcg
[']~
k'g
~
UNITED STATES 4
NUCLEAR REGULATORY COMMISSION 5
'j WASHINGTON, D. C 20555 i
\\.....$
i DR!H Mr. Willitm H. Rasin Director Technical Division Nuclear Management and Resources Council Suite 300 1776 Eye Street N.W.
Washington, DC 20006-2496 i
Dear Mr. Rasin:
We have reviewed the " Design Basis Program Guidelines" developed by the Nuclear; Management and Resources Council (NUMARC) forwarded to-us by NUMARC's letters of May 16, July 2, and October 17,1990..Wc appreciated the opportunity to -
interface with your staff during the development of the guidelines. We note that your staff was responsive to the comments-and concerns that the U.S. Nuclear. Regulatory Commission (NRC) staff expressed during the-develo;, ment of the guidelir;s.
We believe that NUMARC's approach will provide a useful framework and worth-while insights to= those utilities undertaking design basis programs of various -
scopes. We share your view.that no single,best approach exists for a _ design basis program.. We understand that utilities:must often address _ unique situa -
tions. Therefore, a variety of approaches can satisfy:the basic need to-develop :
a centralized location for design bases informati.on>that emr.nasizes the. design.
intent and provides an index to important design' documentation.
We believe that Section VI of the guidelines regarding velidation of.the facility against current design information-is of particular.im)ortance. ~The goal of any design reconstitution program should be to e stablis t confidence-that the existing. facility is-in accorc'ance.with the cur, ent design; documi.s l
and that any deviations are reconciled.
j L
The Enclosure summarizes our thoughts on several areas.that the.NUMARC guidelines do not address-extensively. -You may want to consider issuing l
further NUMARC guidance in these areas as you-. receive respons.es-from utilities-on'use of the guidelines, i
In the near 'uture, the.NRC will issue k NUREG. document containing perspectives on utility design control programs and design document. reconstitution programs gained fre : survey of the programs o/ six licensees and one nuclear steam
-supply y stem ondor. The NUREG docuaent will' contain factual ~ information-regarali.g programs as they were being implemented atlthat time and will: des-crt' e program strengths and weaknesses'~and problems encountered by utilities.
1 e
i rit. William H. Rasin,
.We view your development of the
- Design Basis Program Guidelines" to be a positive step in an area that will continue to be of great importance.
Sincerely, William T. Russell, Associate Director for Inspection and Technical Assessment Office of Nuclear Reactor Regulation
Enclosure:
NRC Observations of Design Document Reconstitutior Programs
[
i l
ENCLOSURE i
NRC Comments on l
Design Docunent Reconstitution Programs (1) Template Approach The design document reconstitution (DDR) process should result in confi-dence that sufficient design docun.:ntation is available (a) to verify the implementation of the design bases, (b) to provide justification that key l
design parameters, such as the pump net positive suction head, are ade-quately accounted for in the design, and (c) to ensure that a structure,-
i system, or component (SSC) will perform its intended safety function. One.
approach to developing a system or topical design bases document is,to first identify a template of design parameters. Such a template would' (a) establish and define the functionality and operability requirements.
i of SSCs, (b) demonstrate the conformance of.SSCs to the design bases, and-(c) demonstrate that SSCs will perform their intended' safety functions.
A review could then be performed to establish the degree to which the available design documents support the parameters defined-in the template.
This process would identify areas that require additional design.
documentation.
(2) Design Document Technical Review The design document reconstitution program should include-a: technical review of the supporting design parameters, design calculations, and analyses. This. technical review would verify that.the design documents are technically sound and consistent with' the as-built facility. The.
available design documents should be reviewed to identify areas-where-design information is technically inadequate or not consistent with.the l
as-built facility.-
(3) Concept of Essential Design Documents.
In performing a design document reconstitution program, certain design documents will prcbably be unretrievable or will,contain inconsistencies.
While the NRC does not advocate the regeneration'of-the complete _ set of L
design documents, it is important that certain design: documents are available to~ support plant operation..The design documents in.this' set
.will be referred to'as the-" essential design documents".-and are further' defined as Category I-herein. All Category I design documents must be accurate, and those that are unretrievable need to be regenerated.
Category I design documents are those documents that-are necessary to support or den.cnstrate the conservatism of' technical-specification values, such as pump flow calculations.or setpoint' calculations. Additional:
design documents included in Category I would,be those necessary for.
(a)engineeringorganizationstousein'supportingplantoperationsand l'
(b) the operators to use in quickly responding.to events.
Exa. 'es of l
Category I documents include, but are :not limited to, electricai load 1
lis'ts, setpoint lists, valve-lists, instrument lists' fuse lists, breaker lists, Q-lists, diesel generator load sequencing, piping and instrumenta-tion diagrams, flow diagrams, electrical single-line diagrams and schemat-ics, and breaker and fuse coordination studies.
(4) Prioritiration of Missing or Inadequate Documents Use of a prioritization methoo01ogy in considering whether to regenerate missing or deficient documents can ensure that the licensee focuses rescuices on the more safety-significant items in a. timely manner. An initia.' screening process would enable the licensee to determine the significance, effect on plant operability, and reportability requirements related to the missing or inadequate documentation.
One way to rank the importance of design documents according to safety significance is as follows:
Category 1 - Design documentation that supports or defines technical specification safety limits, limiting conditions for operation,. limiting safety system setpoints or surveillance requirements.
These documents cemonstrate that the SSCs addressed by technical specifications.will perform their active safety functions.
Category II - Design documentation that defines controlling. parameters or demonstrates the active functionality of safety-related SSCs that are not explicitly addressed by the technical specifications,.but that support the SSCs addressed by technical specifications such as heating,' ventilating,_
and air conditioning systems.
Category III - Design documentation tnat defines controlling parameters or demonstrates active functionality o' safety-related SSCs not included in Categories I or II.
l Category IV - Design documentatian that defines controlling parameters or demonstrates the functionality of safety-related SSCs with regard to passiveconsiderations(e.g.,seismicconsiderations).
Category V - Design documentation that demonstrates the design of non-safety SSCs is such that.its failure would not impair the functionality of safety-related SSCs (e.g.. seismic II/I considerations).
(5) Design Bases vs. Design Document Reconstitution Reestablishment of the design bases.without recon'stitution of the support-ing essentia1' design documents may not provide a sufficient amount of information to support future modifications and current plant operation.-
The objective of a DDR program'is to establish a continuity among the various levels'of design information (e.g., design: calculations and design 4
bases documents) and with the physical plant characteristics of the f acility. The DDR program should ensure:that the design bases documents accurately reflect the source design documents, the design output docu-ments accurately reflect the design bases, and the plant configuration is in accordance with the design output documents.
~,
2-i
This information requiring document reconstitution can be evaluated-in I
relation to the document categories,- as defined herein. The NRC considers that all Category I essential documents that are inaccurate, unretrievable, or not yet produced should be regenerated in an expeditious manner.-
However, a licensee may be able to generate test data'or use other means to establish a high level of confidence that the system can fulfill its-safety functions.
If so, then the licensee may be able to schedule the regeneration of the Category I document in a period.of time commensurate with its evaluated safety significance.
A licensee rey not need to regenerate design documents for Categories 11 through V if other supporting information or test data is available to demonstrate that an SSC can perform its-intended safety function. For example, it may not be necessary to regenerate all missing pipe support calculations if, based on. reanalysis of a sufficient sample. it can be desenstrated that adequate design margins' exist. 'However, if a r.odification is proposed that would affect a pipe support, it would have to be reanalyzed if a valid analysis did not exist.
It is important to stress that a facility should not be; modified unless-sufficient information is available to demonstrate that adequate design-margins will be saintained. Therefore, all missing calculations or design documents necessary'to support a modification must be regenerated to-establish a point of departure'for the proposed modification and to quantify the design margin available following the proposed 11nstallation of the modification.
t 1
l l
r 3'
\\
. [g
'\\',
UNITED STATES 8'
l
{
'.. )c,
~
NUCLEAR REGULATORY COMMISSION e.
wAsmwoTow. o. c, rosss
- \\*..../
l FE8 0 3 1990 l
l MEMORANDUM FOR:
William T. Russell, Regional Administrator, Region !
l Stewart D. Ebneter, Regional' Administrator, Region 11 A. Bert Davis, Regional Administrator, Region III Robert D. Martin, Regional Administrator,_ Region IV John B. Martin, Regional Administrator, Region V FROM:-
Thomas E. 4urley, Director Office of Nuclear Reactor Reg:llation
SUBJECT:
POLICY REGARDING CONDUCT OF INSPECTIONS ON LICENSEE SELF-INITIATED DESIGN DOCUMENT RECONSTITUTION (DDR) PROGRAMS Some NRC inspections performed in the mid-to late-1980s identified problems with the unavailability of design documentation to substantiate the' adequacy of.
plant systems. These inspection results led, in some cases, to. escalated enforcement that resulted in the utility development of _ design document recon-stitution programs. Some utilities'have therefore made specific consnitments-regarding the extent and concuct of their design reconstitution programs.
Other utilities have initiated similar types of design document reconstitution programs.
A series of NRR surveys has been performed at six utilities and'one NSSS vendor to ascertain the state of the industry with respect to design control and the' implementation of design reconstitution programs.. Plant-specific information on the plants-in your region which was generated in the survey has already been-forwarded to your staff. The results of the surveys will be disseminated to~
l the industry in a forthcoming NUREG. The NUREG will form the~basistfor continued discussions with NUMARC and possible regulatory action related to design document reconstitution programs.. The NUREG'will contain guidance.
regarding design control and design change control as well asLutility.DDR-programs but will. not contain prescriptive requirements for.the fonnat3.nd-content of-system or' topical suurary documents. These need to be~ determined by I
the licensees' based on their needs and intended-use of these documents., There are no regulatory requirements regarding the necessity.for sunnary documents to capture the design bases'although we feel-it prudent-that these= documents be developed. -Some information developed in the survey is being provided to NUMARC for their consideration in developing ~a' guidance document (Enclosure).
The industry has established a NUMARC working group to develop guidelines for DDR progranis. They have issued one draft guideline regarding the handling of technical issues that are identified during a DDR program. The Region V
'utih;.ies have jointly developed a guideline that addresses DDR program scope, I
documentation, verification and handling of open items. Neither the NUMARC nor-Region V utilities guidelines have been endorsed by:the-NRC.
I CONTACT:
- Wayne D. Lannins, NRR 492-0967
4 L
FEB e s geo Multiple Adcressees l Sone regions have expressed an intent to inspect the implenentation of self-initiated design document reconstitution programs.
We are strongly opposed to this because 1) regulatory requirements for " design basis documents
- are non-existent, and 2) this would be a-strong disincentive to utilities who are well intentioned and are expending funds voluntarily to create summary design documents for systems.and licensing topics. Therefore, the self-initiated DDR programs should not be directly inspected unless an inspection is performed to verify the implementation of licensee commitments with respect to their DDR program.
This is not meant to constrain the scope of ar.-SSf! type of l
design inspection which cen review the adequacy of 'Se design documentation assentled for a selected system (s) and to verify that this information has b6en-captured by the DDR program.
The intent of this policy is to limit the inspection of DDR program format and content which are structured at the ciscretion of the utility to suit their individual needs.
Criterion-fil of Appendix B to 10 CFR 50 and ASME N45.2.11 - 1974 require that there be an-auditable, trail from design bases (inputs) to design output-documents:to support the as-configured plant. To the extent the system or topical summary 2
design docunents are relied on to meet-this requirement, the technical adequacy of the DDR progran, output is an area which can be reviewed during the perforn.ance of our design oriented team inspections.
If you h6ve any comments or concerns regarding this policy, please contact me.
The responsibility for the NRR effort in this area has been assigned _to the Division of Reactor Inspection and Safeguards.
l Original siga>d by Thomas EL Murley Thomas E. Murley, Director Office of Nuclear Reactor Regulation
Enclosure:
As Stated l
l l
i
(
ENCLOSURE ~
o
/go toa v
'o, UNITED ST ATEs
((
.,q i
NUCLEAR REGULATORY COMMISSION g.
.j wasHmcTow,o c.eosss 5,,+,-
/
t January 30, 1990 l
,g l
l Mr. William H. Rasin, Director Technical Division Nuclear Management And Resources Council 1776 Eye Street N.W.
Suite 300 Washington, D.C.
20006-2496
Dear Mr. Rasin:
We apprec.iate the opportunity to have met with representatives of your Design Basis issues Working Group for the purpose of discussing the first guideline that the Working Group developed on the handling-of open items resulting from.
design reconstitution efforts. As 'you know, we have: conducted a'serit's of surveys (six utilities and one nuclear steam supply system vendor) to develop information on industry design control. programs and implementation'of design reconstitution efforts. Our conclusions from those surveys ~will'be documented-in a forthcoming NUREG report.
In the interim,.we have assembled the enclosed-outline which describes some of the information gained during the, surveys with respect to design reconstitution efforts, i
We trust that the enclosed information will be of value to the Working Group during the development of design reconstitutir,n guidelines._ If you have any connents regarding the information conveyed '.n the enclosure', please contact either myself (492-0903) or Mr. Gene I;:tro (492-0954).
Sincerely, c,. -
\\.
\\
7" pni s
Brian K. Grimes; Director Division of Reactor Inspection and Safeguards.
Office of Nuclear Reactor Regulation _
Enclosure:
As Stated
^
o l'
l.
,.. - ~..
l l
l ENCLOSURE PERSPECTIVES ON DESIGN RECONSTITUTION PROGRAMS The NPC has performed a survey program to gain an understanding of the design reconst1trtion efforts and design control programs that are ongoing in the industry. The survey team visited six utilities and one NSSS vendor. A standardued set of survey questions was utilized to gain specific utility feedback on their practices for design and dosign change control, drawing control, and the availability and accuracy of design documentation. An essess-ment was performed of their design document reconstitution program, if in place.
The survey results are currently being compiled into a NUREG that will pr?v%e NRC reconrnendations and conclusions regarding design control practices i d the ongoing design docunient reconstitution programs based on the survey observations.
l Some of the survey observations are provided below.
Need to Conduct a Design Document Reconstitution Program Th6 perceived utility need for a design document reconstitution program wes found directly proportional with the age of the plant.
Utilities with recent vintage plants have a design organization that participated directly in the initial design and construction of the plant and the design documentation is extensive and retrievable, therefore because of existing corporate memory they do not feel the need to collect the system and topical design bases in a central set of " upper tier" documents.
The following factors were identified as important for consideration by utili-ties in evaluating their organizations to determine the need for. implementing some form of design document reconstitution program:
- 1) loss of utility, A/E, ar.d NSSS vendor engineering and design corporate memory through personnel attrition; 2) the normal evolution of the utility organization from a design to an operating orientation with the typical shift in priorities away from expend-ing resources to maintain and up-date design documents; 3) lack of a central-l ized design engineering organization with the responsibility for design l
control / configuration management shifted to the operating organization;
- 4) extensive reliance upon contracted engineering services with minimal licensee capability to provide technical oversight; 5) the availability of design bases and design-analysis and calculations to support the-1 "as-configured" plant; and 6) the ability to make timely operability determinations.
Design Document Reconstitution Program Scope Design document reconstitution programs have varying levels of information contained within the documentation with respect to content, format, and level of detail. ~1t is the prerogative of each utility to develop their approach based'upon their unique needs.
The general intent of the reconstitution program can be to provide a central location f or design basis information with emphasis on the design intent (the why of the design) and be a top level directory to the design documents that define the current plant configuration.
The end result will provide information that will aid with the preparation of plant modifications and safety evaluations, and.to aid in the development of J
e:
s
(
jt.s'tifications for continued operation.. The end users of the documentation can be identified and the content and format structured accordingly.
Design Casis vs. Design Document Reconstitution One aspect of the reconstitution program is the identification of the functions performeo by structures, systems, and components and the velues or ranges of controlling parameters in accordance with the definition of design bases in.
However reestablishment of the "oesign bases" without-reconstitu-tion of the supporting design documents, as necessary, may not provide a sufficient level of information for the basis for future modifications. The program could also inteorate an effort to-establish that the supporting design documentation (essential documentation) is available, accurate, and that the t
reconstituted design documents accerately reflect the plant configuration.
The:
otjective wouio be to establish a continuity among the various levels of design:
information and physical plant characteristics.
Availability of Design Documentation-Some utilities began licensed operation before the adventiof design document controls such as 10 CFR 50. Appendix B and. relevant ANSI standards. Because of this, and other reasons, the necessary documentation to demonstrate the accept-ability of plant modifications'is not availatle.
The spectrum of design..
documentation can be reviewed to identify the set of essential documentation necessary to support Technical Specification limiting safety system setpoint, i
Technical Specification operating limits and basesi and to' demonstrate that safety systems are designed and are being operated in accordance with their-design bases.
Regeneration of the missing documentation may be appropriate in a time-frame based on the safety significance, i
Control of incremental Chp.ges The surveys found that minor changes involving such things as electrical loads on. Class IE. buses, fluid system resistance,' valve weight changes, and pipe.
l-hanger relocations are not clearly documented within existing calculations when an engineering determination concludes the;1 tem is individually insignificant.
While it may not be necessary to revise major calculations for incremental parameter changes, based upon engineering-judgement, it'is appropriate to track these changes to support the conclusion that the changes.in aggregate-do not affect the validity of the existing calculation and the ability'of a system, structure or component to perform'its design. safety / design functions. - It is apparent that some controls are needed for the logging of incremental changes-such that'they may be assessed in total when a subsequent modification is.
performed.
Operability /Reportability Determinations for Missing Documents l
l A design document reconstitution program can' result in the identification of L
missing design documents with varying degrees of safety significance.; Some may.
be minor inconsistencies in' docuneentation while others can involve the.cossi -
I bility of operating the plant outside.the design bases or:in an'unanalyied-condition that will necessitate immediate' action.
It~1s incumbent on the-
. personnel involved with a reconstitution program to, assess in' c timely manner the concerns that have potential operability aspects.. These~ concerns need to be escalated for a formal uperability review on.a time scale comensurate witb-2 2
--... x
s 4
thefr safety significance.
Applicable technical specification action state-ments are entered as appropriate when the operability determination has been made. A justification for continued operation and an action plan can then be developed as needed on a time schedule conenensurate with the safety significance.
The determination of operability /reportability is a continuous process, if new infornction comes to light which changes the characteristics of a previously identified issue, the operability /reportability aspects need to be promptly reconsidered.
The reportatility decision follows-directly from the operatility determination.
If the operability oetermination reveals that the plant was uperating in an unanalyzed condition or outside its desigr basis, the-item would be processed in accordance with normal reportability mechanisms.
Utility /hkC dialogue during the reconstitution process is appropriate 50 that j
operability issues can could be discussed even if a requirement for formal 1
notificetion is not evident.
Design Document Reconstitution (DDR) Programs Self-initiated DDR programs were found to have several common weaknesses as discussed below.
- 1) The design reconstitution programs reviewed to date have not identifiec in advance the documents that are necessary to demonstrate that a structure system or component will function properly. Analternativeapproachwouldbe to initially develop a template identifying the set of design docupents thbf will te known as " essential dccuments." This " template approach" could serve to define the set of design documents necessary to a) establish and define the functionality and operability requirements of systems, structures and compo-nents, and b) cemonstrate the systems, structures and components conformance to the design bases, and c) identify the available margin. A review could be performed utilizing the " template approach" (i.e., compare the essential document list with available design documents). H1ssing documents would be identified and prioi tized for reconstitution as appropriate.
l Essential documentation could be further subdiviced as follows:
Category 1 - Design documentation that supports or defines technical specification safety limits, limiting conditions for operation, limiting safety system setpoints, surveillance requirements or bases, or that denionstrates that systems, structures or components addressed in the plant's technical specifications will perform their' safety function.
Category II - Design. documentation that defines controlling parameters or demonstrates the functionality of safety-related SSC that are not explic-itly eddressed in the technical specifications but which provide a sup--
porting function to the'SSC addressed in the technical specifications.
Category Ill - Design documentation that defines controlling parameters or demonstrates functionelity of safety-related SSC not included in Category I or 11.
l l
l 3
s 9
Category IV - Design documentation that defines controlling parameters or derronstrates the functionality of safety-related SSC with regard to passive considerations (i.e., seismic).
Category V Design documentation that demonstrates the design of--
non-safety SSC is such that its failure wovid not impair the functionality of a safety-related SSC (i.e., seismic 11/1).
- 2) The process for the regeneration of missing design documentation was not l
ahtays proceouralized so that it could be handled in a systematic manner.-
The regeneration of the missing documents can be based upon the safety significance of the documentation.
Particular empnasis for-regeneration can be placed on documents necessary to.show compliance with plant technical specifications, that define technical specification bases, or those necessary to demonstrate I
functionality of safety systems during postulated accidents or plant transients.
- 3) The valid 6 tion of the content of specific DDR output documentation such'as t
system or topical sunnary design documents was not always thoroughly carried I
out. Some level of valication of the plant configuration with respect to the reconstituted design documents is appropriate.
The validation needs to address functional performance and interface requirements established within the design documents.. Associated plant configuration management-initiatives can be l
integrated into the validation program'as appropriate.
- 4) One important intangible benefit-from a design document reconstitution program performed with strong participation.of the utility's staff is the in-depth understanding that is gained of the plant design bases.: Some utili-I ties that have implemented DDR programs have engaged the services of contracted engineering organizations to develop the DDR sunnary design documents. The end I
result is that the summary design documents are-turned.over to' utility personnel who have not gained a working knowledge or appreciation of the design-considerations embodied in the final design since the detailed review was-performed by contractors.
in this instance, the sumary design document-can become a less than useful. document due to a lack of understanding and.
acceptance of the document by the working level utility staff.
I i
f i -
l w.
.