ML20062D470
| ML20062D470 | |
| Person / Time | |
|---|---|
| Issue date: | 11/01/1990 |
| From: | Advisory Committee on Reactor Safeguards |
| To: | |
| References | |
| ACRS-T-1821, NUDOCS 9011130246 | |
| Download: ML20062D470 (77) | |
Text
hcRST-IfR f
]
- R G y, OFFICIALTRANSCRIPT OF PROCEEDINGS Agency
U.S.
Nuclear Regulatory Commission Advisory Committee On Reactory Safeguards
Title:
subcommittee on plant operation 7
Docket No, l
=
A Bethesda, Maryland mg Thursday, November 1, 1990 1 - 51 g
pg
=
ACRS Office Corp - Re:a'~
l tJ m
Or the !_iie of 1.'e Co-- ~ 1:ee j
-E
_su ANN RILEY & ASSOCIATES, LTD.
1612 K St. N.W Suite 300 Washington, D.C. 20006 (202) 293-3950 p.jilgpovotio' m o.,
1.
g
- 1 s.
3-4 PUBLIC NOTICE BY THE 5
UNITED STATES NUCLEAR REGULATORY COMMISSION'S 6
ADVISORY COMMITTEE ON REACTOR SAFEGUARDS 7
i 8
DATE:
Thursday, November 1, 1990 9
10 r
11 12 (13 The contents of this transcript of the
-14 proceedings of the United States Nuclear Regulatory 15' Commission's Advisory Committee on Reactor Safeguards,-
Ll6 -
(date)
Thursday,1 November 1, 1990-
.17.. :
as reported'herein, are a record of the discussions recorded at i
- 18:
the meeting held.on the above date.
lL!L This transcript has not been reviewed, corrected I
20 or edited, and it may contain inaccuracies.
21 1
- 22 23-b 24 l
25-t
. ~ _..
l 1
1
- , / S.
1 j
)
2._
UNITED STATES OF AMERICA 3
4 NUCLEAR REGULATORY COMMISSION
-t 5
6 7.
ADVISORY COMMITTEE ON REACTOR SAFEGUARDS
+
8 SUBCOMMITTEE ON PLANT OPERATION 10 11
" Reconstitution of Design Basis Documentation"
.12 >
1.
tr~g
'.13' Q..
1.
14 Thursday, November 1, 1990 L.
1!5 Nuclear Regulatoryfcommission-16 Conference Room P-110
-17 7920 Norfolk Avenue
'18 Bethesca, '43ryland 19 i,
20=
The Subcommittee' met, pursuant to notice,.at.1:20
.21
~o' clock, p.m.,
where present were:
" ! 22 J. Carroll, ACRS Subcommittee Chairman
.23 C. Michelson, ACRS Member 24 P. Shewmon,-ACRS Member 25
~
2 1
PRESENT, CONTINUED:
(
2 E. Wilkins, ACRS Member 3
P. Boehnert, Cognizant ACRS Staff Member 4
E.
Imbro, NRR/NRC 5
G.. Grimes, NRR/NRC 6
T. Pietrangelo, NUMARC 7
A. Marion, NUMARC 8
9 10 11 12 L
14 15
~ 16.
17 18 19 20 21 l
22:
-23 24' 25
3
- L PROCEEDINGS f-.
2 _-
(1:20 p.m.)
i o
3 MR. CARROLL:
Good afternoon.
The meeting will 4
now come to order.
This is a meeting of the Advisory 5
Committee on Reactor Safeguards, Subcommittee on Plant 6
Operations.
I am J.
Carroll, Subcommittee Chairman.
The
-7 ACRS members in attendance are Carl Michelson -- or will be f
8
-- Paul Shewmon and Ernest Wilkins.
9 The purpose of today's meeting is to be briefed by 10
.the NRC and NUMARC on their efforts concerning s
11 Reconstitution of Design Basis Documentation for Nuclear 12
. Power Plants.. Paul Boehnert is the cognizant ACRS staff i
I g'w) 13'
. member for this meeting.
14 The. rules-for participation in today's meeting 15?
have been announced as-part of the notice of this meeting 16 previously published'in the Federal Register on October 17, j
.i 17:
1990..
A transcript of the meeting is being keptLand will be.
i 18 made available'as stated in.the Federal ~ Register Notice.
19 It.is requested that each speaker first identify 20 himself or herself and speak with sufficient clarity and 21 volume into a microphone sua that he or.she can be readily a
f'-
22 heard.
We have received no-written comments or requests to
.3 make oral statements from members of the public.
2 Do any of the Subcommittee members have anything 24 L
)
25 they'd like to discuss at this point?
l l
1
4 1
.[No response.)
q^p 4,)f 2
MR. CARROLL:
Okay, we'll then proceed with the 3
meeting, and I'll call on the staff to begin.
4 MR. IMBRO:
I'm Gene Imbro, Section Chief in the 5
Special Inspection Branch.
6 MR. CARROLL:
Who are you?
4 7
MR. GRIMES:
He's going to make the presentation.
t 8-Let me introduce myself; I'm Brian Grimes, Reactor
+
9 Inspection Safeguards Division.
10 (Slide.)
i 11 MR. IMBRO:
I am Gene Imbro with NRR in-the 12 Special Inspection ~ Branch.
I'd like to talk to you today rN 13 about-the Reconstitution of Design Bases and Design d
'14
' Documents.
The subjects I'm going to cover today are first 15 of all,.trying.to define what design documents are, go 1
16.
through a little bit of the NRC efforts we've gone through 17 to put together~a NUREG, provide some observations on 18!
utility' programs.and also to give you some of the 19 ebservations.on some of those utility programs that we've l
20 seen..
21" MR. CARROLL:
Brian and Gene, this is strictly a 22' briefing to us?
You're not expecting a letter or a formal 23 comment necessarily?.
-24 MR. GRIMES:
That is correct.
It's just a
'!9 i
\\d 25 briefing to update you on what we're doing at present in i
5 1
this area.
2.
(slide.]
3 MR. IMBRO:
Just to go through quickly what 4
prompted the utility efforts in reconstitution of design 5
bases, NRC has been conducting team inspections probably for 6-the last-five years since 1984 or 1985.
Those have been 7-basically safety system functional inspections and safety 8
system outage modificatior inspections.
9 There's kind of a common thread that goes through 10 all of these inspections.
When we look at the facility
.11 design, particularly of older facilities, many of the design 12 documents are-not available to support facility
- W.
13
-modifications.
1 i
V, 14
.As a result of the inspections we've conducted, 15 utilities really became cognizant of the fact that this was, 16 in-fact, a problem and they, on their own, have initiated 17' design document reconstitution programs.
18
-)GR. SHEWMON:
Actually, in the case of the
'19 pressure vessel and welds, often they don't have samples H2 O from-the way_it was done originally, much less the 21 modifications.
Is that also a part of the program?
22 MR. IMBRO:
Well, we didn't look at that level of 23 detail, but that's true in general.
In a lot of cases, not 24 only'is the documentation to support modifications-not
- ,p -
'ks 25 available, but also, many of the findings we have go back to
6 1
the original design'and, in fact, there's a lack of original q
(,/
2 design material.
3 (Slide.)
4-MR. IMBRO:
We started to talk about design basis t
5 documentation and we found out that there were a lot of 6
different definitions of design basis documentation.
People I
7 perceived things differently.
8 Of course, when we talked about missing design 9
basis documentation, we were really referring to not only 10 the design bases and design criteria, but also the 11 calculations'that show how the design basis is implemented i
12 and the design output documents.
Some utilities perceive
~S. : 13i Ethe terri design basis documentation, to mean just the 1(O 14 design.r'.cerla, so some utilities focused on, in the design h
R15 -
document' constitution programs, focused on strictly
' 16 =
regeneration ~of criteria..
17 What was used as design input for the plant?
So, i
18 whenuwe-talk'about design documents -- we basically use the 191 Eterm-design-documents to kind of make it more sweeping, that.
l 120L we don't only mean design bases but we mean all the design-L 21
' documents.
i L
-22' (Slide.]
2 l
23 MR. IMBRO:
The design documents kind of fall'into E
24 three~different categories which are fairly obvious.
The lf3 N) 25 first category is what people would refer to as design input m
1 l
?
J 7
1 documents and you know, they are the RC regulations, le 2
guidance presented by the Standard-Review Plan and Reg 3
Guides, industry standards, design procedures and the like.
4 Certainly, the vendor specified data, vendor performance 5
- requirements are also a-design input.
6 Then, I guess, skipping across, the final design i
j 7
output documents would be the things that are used to 8
procure equipment-and construct the facility.
You're 9
talking about things like drawings, purchase specs, setpoint 10 lists, valve lists and the like.
L 11'
.The bridge between those two is really the design L
'12 ~
analyses, what translates the design input to the design
]
13 output.
j)3 s
(
1 14 MR. MICHELSON:
Gene, there seems to be one step 15 missing in that slide.- Maybe it's in there and I just don't L
161 see it,-but admittedly, there are-a large number of L
~17 requirements and' regulations which we call here design input
' 18 -
documents.
The key element, though, in getting on to doing 19 design analyses and producing output is to interpret the
- 20 input documents.
21 That interpretation' step is extremely.important so l
22 that you-know how the designer interpreted.the. regulations; 23 in other words, what did he think they were saying and
(
- 24-therefore, what he's going to provide.
p)
(_,
25-Where is that interpretation step in your process?
i w-
8 1
That's got to be documented.
It's very important to know
()
2 how the person interpreted the regulation.
3 MR. IMBRO:
It's really this transition from here 4
to here.
It's not really defined per se.
5 MR. MICHELSON:
The hardest thing to find lately.
6 Sometimes it's there.
A 'ot of things don't have system
)
7 descriptions.
System description doesn't fit a lot of the 8
situations, a lot of calculations and evaluations.
They 9
don't fit the system description idea, buc there has to be 10 some kind of a transition document which is really your 11 design basis as you interpreted it from the regulations and 12 all the other things.
13 MR. GRIMES:
The calculations and evaluations have 14 to indicate what their input is and what their assumption 15 are.
16 MR. IMBRO:
I would put that in this box, Design 17 Procedures.
That's how the AE's or whoever is designing, 18 interprets all these documents and implements them.
19 MR. MICHELSON:
That's the difficult information L
20 to recover later; is, okay, I know what the regulations said i
21 then and here's what they did, but something happened in 22 between.
How did that individual go astray or how did he l
23 interpret the regulations incorrectly.
l 24 He might have had quite good logic on what he did.
-25 It's just not documented and we never know later.
I guess ss
=
9 1
it's not possible to recover, but in the future, it ought to
()
2 be a part of your requirements.
t 3
MR. CARROLL:
I guess I would view what you are 4
describing as part of the evaluation.
5 MR. MICHELSON:
In a way, yes, but you have to 6
make a lot of assumptions.
7 MR. GRIMES:
I think one thing that will come out 8
later, when Gene describes the survey results, is that i
9 everybody had a different design configuration process, and 10 everyone has a different set of documents and a de :ument i
11 logic to go with that.
So, we have shied away from 12 specifying specific documents, but we expect certain things 13 to be accomplished.
t sg s C ' 14 MR. MICHELSON:
I expect you should be able to 15 find somewhere what are the interpretations of the 16 regulations.
It's different than assumptions.
It is the 17 interpretation of a regulation.
18 (Slide.)
19 MR. IMBRO:
Your point is well-taken, and many 20 times, in doing inspections, or particularly when we were 21 doing IDVPs or looking at IDVPs for reactors that were about 22-to be licensed, you'd have different AEs conflicting over --
23 in our company, we interpret the code to mean this, and P
24 another AE says, no.
So, you raise a valid point.
,r' 25 I just wanted to talk a little bit about
10 1
1 regulatory design bases and engineering design bases, and (Q,/
2 this is kind of a little bit of a sticky thing, I guess, but 3
the regulatory design basis, I think we're being consistent 4
with what's termed current licensing bases for life 5
extension, but for a regulatory design bases, we mean
)
1 6
basically the documents that were looked at by the staff to i
7 form their safety judgments on the licensing documents for 8
the plant.
9 So, you have, again, rags, toch specs, the SER, 10 all the licensing commitments, and actually, there is a 11 definition of design bases in 50.2.
The engineering design 12 bases is really a lot broader set of information and O
13' criteria.
V 14 It includes, certainly, the regulatory design 15 bases, but it also includes a lot of other things that the 16 staff may or may not consider, because-they're not really 17 directly safety-related, and in a lot of cases, the non-18 safety-related functions sometimes are the determining 19 factor for the size of the safety-related equipment.
So, 20 the engineering design basis is a little bit broader.
21 Also, it includes so-called good practice 1
22 documents and standards.
So, the engineering design basis 23 is pretty much all-encompassing, and that will be kind of 24 what an architect or a designer would use as the total (3
's-25 design input.
11 1
(Slide.)
i 2
MR. IMBRO:
Just quicxly, to go through why design 3
documents are necessary, certainly, as the slide indicates, 4
you really need to have documentation available to support 5
plant modifications, and in +he case of a new plant, j
6 certainly if the original documentation is not there to 7
document the design, then certainly it's hard to modify the 8
plant if you don't know where you're starting from.
9 In the same vein, the documents really help you in i
10 making a plant modification, to help you quantify design 11 margins and design envelope, operating envelope, and 12 certainly, it's basically the record cr the as-configured i
/
13 plant.
L 14 (Slide.)
{
15 MR. IMBRO:
What we did as a staff is we had been 16 aware of many utilities going out and spending, in some I
17 cases, substantial sums of money to recreate design 18 documents, and we decided that it would be appropriate for 19 us to go and look and see, more or less, what their process 20 was and.to try and understand, give us a handle on what the 21 status of the industry was in terms of design documentation,.
22 how much was really available, how good or bad was the 23 situation in terms of document availability.
24 So, we visited six licensees, and we talked to one 25 NSSS vendor, General Electric, and we looked at the s
~.
12 1
availability of design documents.
We also looked even p) 2 further.
We looked at how utilities control their design i
3 and how they made modifications to the plant and how the 4
utility groups interface with each other, and for some 5
utilities, of the ones we visited, that had design 6
documentation programs, we tried to gain an insight into 7
what they were doing and what their approach was.
8
[ Slide.)
9 MR. IMBRO:
As a result of our limited survey --
10 MR. CARROLL:
Which utilities were those?
11 MR. IMBRO:
In the next slide, I will get to that, 12 if you'll bear with me for just a minute.
f-"s 13 Basically, we intend to put out -- issue a NUREG, tj 14 which has kind of been a long time in the making, but it 15 should'be out, hopefully, before the end of the year, and 1
16 the NUREG is going to -- will be a good practice NUREG.
+
17 It will talk to the following areas:
what design 18 documents we think should be controlled and should be 19 maintained as configured; if design documents need to be r
20 reconstituted, if you find, when you do your survey, do your 21 design documentation program that design documents are 22 missing, which ones do you need to regenerate and which 23 ones, maybe, do we not have to regenerate.
24 Also, we like to give some insights into the
>p i
=25 strengths and weaknesses of some of the utility-initiated
i 13 i
i design reconstitution programs and talk a little bit about
. (')
2 configuration management.
The thing is, though, that each
-l 3
licensee really has given us a different perspective that we 4
have gone to see, and certainly, each licensee has their own 5
particular needs.
6 So, it's really hard to -- there is not one 7
program that will suit everybody.
Each utility really needs 8
to do their own thing, as it were, because they have 9
different organizations and they have different needs.
10 (Slide.)
11 MR. IMBRO:
For the licensees that were surveyed, 12 we tried to take a mix of new and old plants, and so, we Sr 3 13 went through Robinson, which is certainly old, or older, b
14 Susquehanna and Diablo Canyon, which are fairly new.
Fort 15 Calhoun is an old-generation plant, as is Crystal River and 16 Turkey Point.
17 So, we tried to get kind of a cross-section of 18 what different people were doing and what the different 19 status of design documents was.
20 Yes?
21 MR. SHEWMON:
Crystal River is combustion, and 22 Turkey Point is Westinghouse?
23 MR. IMBRO:
Turkey Point is Westinghouse.
Crystal 24 River is B&W.
25 MR. GRIMES:
Fort Calhoun is CE.
't a
s
-.e.---~
wm v
n w.
w.
14 1
MR. IMBRO:
It's Westinghouse, BWR, GE,
~
(}
2 Westinghouse, CE, B&W, Westinghouse.
\\.a 3
MR. CARROLL:
Now, of those six utilities, only 4
PG&E has historically done its own engineering and 5
construction management.
6 MR. IMBRO That's right.
It's kind of 7
interesting, because older utilities, at least at that time, 8
the time of the survey, which is probably about a year and a 9
half ago, older utilities didn't really see the need to do 10 DBDs.
11 The utilities that had newer plants, like PP&L and i
12 Diablo Canyon, really didn't see the need to do them at that t
13 time.
PGEE had something that was kind of like a DBD, but t
14 it wasn't -- but the purpose was more to provide the 15 operation staff with an insight into the design, rather than 16 a document to be used by designers, because they felt that 1
17 they had adequate documentation and they really didn't need 18 a design document reconstitution program, primarily, as you 19 say, because they were their own AE.
~
20 From an NRC point of view, we don't really -- we 21 haven't really forced people to do design document 22 reconstitution programs. - However, we do require that they 23 have adequate design documentation.
So, whatever it takes 24 to get there.
)
25 MR. SHEWMON:
I guess I am trying to -- I'd like
_ _ _ _ ~ _ --
15 1
to back you up about two steps, I guess.
The reason you're 2
doing this is that for plant life extension, you have to 3
know what the design basis is.
Is that right?
4 MR. IMBRO:
That's probably true, but that's not 5
really the reason we started.
6 MR. GRIMES:
That may be a side benefit, but the 7
reason we started was, starting with the Davis-Besse event, 8
we realized there were a lot of problems in functionality of 9
safety systems that related directly back to engineering and 10 the control of engineering, and so, we started doing safety 11 system functional inspections and outage modification 12 inspections.
Those gave us a lot of results where there 13 were clearly safety systems that would not have responded in 7_
\\
14 the event of a challenge.
15 Utilities recognized the validity of those 16 findings and began on their own looking into the root cause 17 of that, which both we and they agreed, in many cases, was a 18 lack of good configuration control in their design process
+
19 and a lack of access to documents, so that the engineers 20 doing modifications to the plant could really know why the 21 system was configured the way it was and take that into 22 account.
23 MR. MICHELSON:
-- design basis for the motor 24 operated valves so they had incorrectly adjusted them in AV 25 some cases.
16 1
MR. GRIMES:
That's right.
2 (Slide.)
3 MR. IMBRO:
I guess what we're expecting in terms 4
of level of design documentation -- I guess expecting 5
utilities to have -- is, first of all, we've got to define 6
the term " essential design documents" and essential design 7
documents, we feel, is those documents that are used 8
frequently by the operating staff during normal plant 9
operation and to respond to events and also documents that 10 are used by the engineering -- by engineering -- to support 11 plant operation and, you know, some of those things would --
12 naturally, we would expect utilities to have up to date P &
n 13 ids and single lines and schematics.
'~_l]'
14 And from the engineering side they would need to 15 have as an essential document those documents that support 16 tech spec values and that type of thing.
17 So, as a minimum, we'd like to see utilities to 18 have essential design documents and also then if they go
'19 ahead and decide to modify a system they certainly should 20 recreate whatever documentation they need to form the basis 21 of the modification.
And you have to regenerate whatever l
22 you need to do that.
23 (Slide.)
24 MR. IMBRO:
We felt that for some of the older 25 plants it's rather unreasonable to ask them to go back and
17 1
regenerate design documentation that maybe was done 20 or 25 2
years ago and was lost over the years.
To ask some 3
utilities, particularly that have older vintage plants to do 4
that, I mean, is asking them to spend probably hundreds of 5
millions of dollars.
And in a lot of cases it's not 6
necessary.
So we tried to have a balance.
7 We found that where we found the most problems and 8
particularly with some of the plants -- TVA plants -- was 9
that utilities tend to get in the most trouble when the 10 engineering group doesn't have the design authority.
It 11 doesn't control the plant design.
12 When operations really drives the design and 13 controls the plant design bases it's probably more likely i
14 when you're going to see things go amuck.
People have 15 different focuses.
16 So we certainly advocate strong engineering 17 organizations that control the design bases.
18 (Slide.)
19 To get to survey observations for the design 20 reconstitution programs that we saw, I guess we were able to 21 draw the following conclusions -- observations.
22 We feel that, although all utilities may not need 23 design document reconstitution programs, all should evaluate 24 whether or not they need to embark on such a program.
They 25 should look at the design documentation they have now, look m
18 1
at the staff turnover.
Are a lot of senior people still r
2 there or are a lot of senior people planning to retire?
Are 3
they going to lose all this wealth of information shortly?
4 How easy is it to make modifications?
In some i
5 cases, you go and talk to utility and they'll tell you that 6
half the engineering hours spent in doing a modification is 7
trying to retrieve the documents.
8 And so people really need to do some self-9 evaluation to decide whether or not tiey need to do a I
> 10 program.
And if they.do, they should do it.
11 Not surprising, the need for a DBD program is 12 proportional to the facility age.
Documents tend to get 13 lost over the years.
Either that or else they're not
('s 14 maintained.
They're not kept up to date.
l 15 Again, design documentation programs should meet 16 the unique utility needs because everyone really operates 17 differently.
So in doing self-evaluation I think it's 18 important that utilities decide what exactly they want from l
19 a DDR program before they start and then craft the program 1
20.
to that model.
21 One thing we felt that was also particularly L
22 important was utility staff involvement in design 23 documentatian review programs.
24 It would seem like some of these utilities are 25 spending 20, 40, $60 million, and if you're coing to have
i 19 1
all that done by contractors it seems like there's a lot of i
_2 wealth of information that's kind of then retained in the 3
minds of the people that are doing it.
It would seem lika 4
to have your own staff involved in that would be certainly 5
beneficial, first of all to get them smart as to how the 6
plant was designed.
And, certainly, you would retain -- be 7
able to retain that inhouse.
But also it gives your staff 8
more of a sense of ownership for the system.
9 So I think it's important if a utility embarks on 10 a DDR program they shouldn't just turn it over to a 11 contractor and say, hey, produce me a set of design bases 12 documents.
They should really work with the people.
(h 13 As I mentioned before, stronger inhouse V
14 capabilities are needed, too, I think -- and not all 15-utilities.
I'mean, the larger utilities have pretty large 16 engineering staffs, l'
17 Some of the small ones, though, rely heavily on
-18 outside contractors to do plant modifications.- And 19 certainly there's nothing wrong with contractors doing 20 modifications.
I' mean, they certainly do a good job, but it
- 21 would seem like for the utility to rea,'ly understand their 22 plant and'to retain ownership of the design so to speak they 23 should at least have enough inhouse capability to ask 24 intelligent qucst. ions about how the plant is being modified.
25 I-mean, after all, they own it.
They operate it.
And so
l 20 1
they should understand it.
2 MR. WILKINS:
Imt me ask a question in that 3
regard.
There's a modification that they want to turn over 4
to a contractor.
Who originates the modification?
The 5
utility?
6 MR. IMBRO:
The uti.\\ity would.
Sure.
7 MR. WILKINS:
Yeah.
Of course.
So somebody in 8
the utLlity must have had some reason to think that the 9
modification was desirable.
10 MR. IMBRO:
Oh, it's not a question of desirable 11 but it's how it's implemented.
You know, did the designer 12 do the right thing?
Did they ask the right questions?
Did 13 they do the right analyses?
Did they use the right 14 criteria?
15 MR. WILKINS:
And why did they do it this way 16 instead of that way?
17 MR. IMBRO:
Right.
Don't just go out and order it 18.
and say, look, I want it.
And then put it in and then just 19 stand back and kind of walk away from it.
20 Te my mind people should be involved.
At least 21 should be smart enough to ask the right questions.
I mean, 22 they might not have to know how to do all the work because a 23 lot of distress analysis and thermohydraulics analysis is 24
. pretty arcane and maybe very few people know how to do them 25 and all the ins and outs.
But I guess it's my feeling that
21 1
utilities should at least havt staff that's sufficiently up
)
2 to speed on those to ask the right questions as to what's 3
being done.
4 Also, with DBDs if you go through all the trouble 5
of -- and expense of -- the developing of a set of design 6
bases documents, then you certainly should keep them updated 7
and maintain them as built with the plant.
8 And I guess, obviously, one of the other benefits 9
is they would cut down on all that time spent during the 10 modification process of trying to retrieve documents.
11 (Slide.)
12 MR. IMBRO:
We are advocating the utilities use --
13 it's a suggestion -- kind of a template approach in sitting 14 down and developing DBDs.
Whtit I mean by a template 15 approach is it's hard to know what's missing unless you know 16 really what you're looking for, so before-people or 17 utilities go out and develop a D3D program or develop a DBD, 18 they should first ask themselves the question of, Well, what 19-information do I really need to have to assure that system 20 is going to perform its function, and what parameters do I 21 need to know, and what ranges of the parameters are 22-acceptable?
23 Once you have that in hand, then you can go 24 through the boxes of documentation, and after you finish, h
25 you know what you have and what you need, and whether or not
22 1
you need to reconstitute it.
)
2 Again, some utilities, we found, tended to do 3
this, just reconstitute design bases, but we also feel that, 4
in some instances, they really should give some 5
consideration and regenera'ce supporting calculationn.
6 That's what we found before.
7 Another thing we found was that in some instances, 8
there was no defined prioritization program to regenerate 9
missing documents.
Again, we're not saying that you need to 10 regenerate everything, but at least you need to decide what 11 has to be regenerated, and then also then put it into some 12 prioritization scheme.
13 some utilities were pretty sophisticated, and they 14 are using a PRA approach to determine the safety 15 significance of the missing information, and they use that 16 to prioritize whether or not missing documents or what 17 scheduled documents need to be regenerated.
18 others used kind of more of an engineering 19 judgment type of approach, and some other utilities just put 20 them aside and said, Well, I know this is missing.
I guess 21 I'll regenerate it when I finish the program, or that type 22 of thing.
But we obviously don't think the last approach is
-23
.very good, and people should think up front about how 24-quickly the need to regenerate some of those missing 25 documents.
23 i
i I talked about essential documents before.
I 2
won't go through that again.
3 One thing we really think is very important is 4
that utilities need to do a field validation of DBDs.
Once 5
you spend all the money to finally figure out what your 6
design bases really are, then you should go out in the plant 7
and say, Okay, now that I know what my criteria are, does 8
the plant still need them?
After 20 years of modifications, 9
do I still need my design bases?
So we think that just 4
10 creating shelves of paper doesn't really do you a whole lot 11 of good unless you go out and make sure t *. tat the plant 12 really does neet what you think it should.
13 Also kind of in the same vein, we've noticed that 14 in looking through design documentation that was available, 15 people would kind of take a calculation at face value and 16 not really verify whether or not it was still valid or still 17 accurate.
People would just kind of tend to say, Well, I 18 have a calculation for NPSH for the safety injection pump.
l 19 That's okay.
Check the box and go on.
20 We feel that, certainly for the CALCs that have 21 gone through the Appendix B independent review, that you 22 don't really need to do a detailed technical review to 23 verify what's already been done before, but certainly, if 24 you giye it a sanity check,.and say, Hey, does it still 25 match the plant if the calc was done 25 years ago?
Is the
24 i
i i
cale still valid?
Are the assumptions still reasonable?
2 That type of thing.
3 (Slide.)
4 MR. IMBRO:
As a final slide, operability and 5
reportability was really a major concern of utilities we 6
spoke with, and there was always the question of, If I don't 7
have documentation to justify a system design, is it 8
Do I need to report it?
9 There were a lot of cases in the beginning where 10 people were cycling their facilities pretty regularly 11 because they didn't have design documentation available.
12 They'd almost begin kind of a shutdown process until they 13 were ab)e to recreate the design documentation or determine 14 whether it was a problem.
15 I don't want to get into a whole lot of detail on 16 this, but the staff now is putting out guidelines on 17 operability, operability determinations, and pretty much, 18 the nuts and bolts of it is you really need to look at the 19-safety significance of the information that's missing,' and 20 you need to make a judgment as to whether or not you think 21 that the information is going to cause you a problem or not, 22 or the fact that it's missing.
Do you think the outcome is 23 going to be okay when you regenerate the information?
24 MR. SHEWMON:
You said three sentences ago that 25 they were cycling up and down, or this is --
25 1
MR. IMBRO:
In some cases they were, yes.
()
2 MR. SHEWMON:
Could you give me an example of what 3
would cause cycling and tell me what the period of these 4
cycles are?
Are we talking about quarters or weeks?
5 MR. IMBRO:
I mean, it's not cycles in that term.
6 What I meant was that, you know, if they found a piece of 7
design documentation missing, the plant might be in an 8
orderly shutdown.
In some cases, I think they may have shut i
9 down plant until --
j 10 MR. SHEWMON:
It was safe yesterday when they were i
11 ignorant, but today, we're smarter, so we have to shut the 12 plant down.
Is that it?
9~
13 MR. IMBRO:
Oh, we didn't say that was a good
('
r 14 idea, but people were kind of confused and said, Hey -- you i
15 know,'they didn't really know what to do.
They knew that 16 there was documentation missing.
They didn't know if the 17 plant was safe or not safe, and I guess they said, Well, if 18 I don't have the documentation, I'll just declare a system 19 inoperable and follow my tech specs as kind of the safe --
I 20 you know, what they perceived was the safe thing to do.
21' But you're right.
I mean, the plant's been 22 operating-for 20 years.
The fact that you don't have a 23 piece of paper doesn't necessarily make the system 24 inoperable when it's been working fine for all these years.
( )
.25 That's why it's kind of a good lead into the
.--.mm m.
26 1
premise of operability.
We basically are saying that the 2
fact that the doc umentation is missing doesn't necessarily 3
mean the system is inoperable.
4 You can presume the system is still operable, I 5
mean, providing you have some engineering basis to do so.
6 Not necessarily documentation, but use reasonable 7
engineering judgment, maybe look at test data, surveillance 8
data, start-up test data, whatever else you can, and if you 1
l i
9 can reasonable conclude that the fact that the documentation j
10 is missing doesn't really cause a problem, and you have a 11 high level of confidence that the system is designed okay, 12 then, you know, just keep on going.
13 Also, the question is -- the point is that the p
. V.
l 14 decision process needs to be kind of continuous.
I mean, as 15 you discover new information, then you really need to re-16 evaluate whether or not your original decision was correct.
17 So it's kind of an itsrive type thing.
18 Ret **. ability.
Basically there is no change in 19 the reporting requirements.
If you find you are operating 20 outside of your design basis, then you need to report it by 21' 50.72 or 50.73; whatever is appropriate.
<22 One thing we -- an* NUMARC probably will talk 1
23 about this a little bit later, I suppose.
In the -- 3et me 24 talk a little bit abcut the NUMARC guidelines.
NUMARC has 25 put out a design -- I guess you have a copy of it -- their
l 27 1
program -- design basis program guidelines.
We've 2
participated with them over the last year, year and a half I 3
guess in developing it.
They've been very responsive to the staff comments 4
5
-- have incorporated a lot of the staff comments and are in 6
the process of putting out a letter basically saying that 7
the NUMARC guidelines form a useful basis for people to use 8
the craft or DBD program and also provide some -- some 9
reasonably good insights into -- into the DBD process.
We 10-think it is a worthwhile document and a lot of what I'm 11 saying here is also -- is contained in the NUMARC document 12 and'they -- they and the staff were in agreement on the 13 position.
14 To get back what I was saying.
One of the things
' 15 NUMARC proposes and other utilities have proposed in some 16 meetings with NRC is that rather than -- if you're going to 17 file an LER, rather than developing a corrective action for 18 each LER, which you may do anyway; but what you should do is' 19 then wait until you've finished the DBD and look at all the 20 LDR's again in total and.see whether or not there's 21 something that falls out of -- out of the combined picture 22-and maybe that -- maybe that will identify additional 23 corrective actions that are needed.
24 So, those kind of -- ti.en take -- after you've 25
.aone -- looked at the original fin 0ings, it's time to step
28 1
back and look at what it means in total.
2 NRC's enforcement policy has been changed once to 3
basically encourage utility initiator programs.
Certainly 4
utilities were concerned with the fact that if you spent 5
millions of dollars, then would the staff then turn it 6
against them and say, hey, but you operated outside of your 7
design basis and then possibly be cause for a violation or 8
civil penalty.
9 I think the enforcement policy was changed once to 10
-- to reflect the fact that if you -- if you do find a 11 situation that would be a violation; I believe it's for 12 anything' Level 3 or less, that the staff would waive the 13 civil penalty, but issue the violation.
I think presently 14 under consideration in enforcement policy is another change 15 that's yet to be promoted in which the staff is considering 16 then not only eliminating the civil penalty, but then also 17 to not even site or give a violation.
"' hat's something 18 that's being considered by the staf f r aw.
19 So, that basically concludes my part of the 20 presentation.
Any comments, questions?
21 MR. CARROLL Do you have any plans to expand all 22 this good advice to somebody starting with a clean sheet of 23 paper on a certified design, or on a certified plant?
24 MR. IMBRO:
Well, I mean, certainly, as we 25 discussed yesterday, we think that design bases and system
29 1
descriptions and that type of information should be properly k
2 certified.
Even as I discussed before -- even some of the i
3 newer plants that we visited or even people that we didn't 4
visit, have decided that they really need a design document i
5 for a reconstitution program because they feel that -- they 6
see the mistakes that have been historically made.
They 7
don't want to repeat those; they don't want to get into a 8
position 10 years from now where they don't have design 9
documentation, j
10 MR. CARROLL:
Yes, and if you do it right from day 11 1, the other thing you can do is -- is develop the database I
12 or 'a very sophisticated computer-based information
/i 13 management system so you can really find things in a hurry.
14 You want to know how many of this kind of relay and where 15 they are is and that sort of thing.
16 MR. IMBRO Yes.
We've seen some at some of the 17 plants we visited.
I-think Crystal River had a -- it seemed 18 like they had a pretty good system.
I forget what they call 19 it -- Configuration Retrieval Information System or i
20 something like that.
But they had all plant information on 21 optical disks.
You could go in by part number and pull out 22 everything you ever wanted to know about a particular valve.
23-I guess you could sort it probably any which way you wanted.
24 So, yes, I think a lot of people are developing that 25 capability.
But, you're right.
It's easy to start with it
30 1
up front and as you proceed with the design, to put the
()
2 information into the system.
3 MR. SHEWMON:
To pick a utility at random, did 4
PG&E have something like that?
5 MR. CARROLLt Yes, we do, but it -- it -- it cost 6
se $7.5 million to reconstitute the component database or to 7
put a decent component database together for our PIMS 8
-System.
We literally had to go out and look at the 70,000 9
components on each unit to make sure we knew what we had 10 there for starters.
That's why I'm sensitive to -- if you 11 really set up a program with that kind of end in mind at the 12 beginning of a design, you'd sure be miles ahead.
13 MR. SHEWMON:
Yes, it does sort of bring up the 14 question of -- I guess you brought up, future plants before 15 and if somebody does have an outside AE do their work for 16 them, what kind of a package do they get delivered, or where 17 do the records -- what sort of a package -- what sort of 18 paperwork package do they get delivered and will it be any 19 different in the future than it has been in the past after 20 you've got done doing what you're doing now and what NUMARC 21' is going to tell us about?
22' MR. IMBRO:
We would hope so cert.tinly, but in 23 fact, some of the things we've seen in the past is that --
24 you know, it's all kind of a contractual thing, where you'd
)
25 go to a. utility and ask to see certain calculations and
31 1
design documentation and they'll tell you, well, we never
()
2 got it from the AE because the AE was never -- it wasn't 3
part of our contract to get the calculations.
We bought a 4
plant, we didn't buy the design so to speak.
5 KR. SHEWMON:
You don't think its existence should 6
be part of the regulations; you see no basis for that?
7 MR. IMBRO:
Well, I'm not saying, I don't know 8
whether it should be part of the regulations -- I'm not 9
disagreeing that it's a good idea.
Whether we'd push it 10 that far --
11 MR. SHEWMON:
Well, I'm asking --
12 MR. GRIMES:
Well, we have certain requirements 13 for knowledge of design control when you make modifications 14 now.
I guess our focus is mainly when you -- when you 15 modify the plant you have to establish that you know what 16 you're working with before you modify it.
As time goes on, 17 we expect to see, even without these programs, better and 18 better design documents as you work on different parts of 19 the plan.
-20 MR. SHEWMON:
That is a regulation that you have 21 to know what the design basis was before you should --
~
22-before you modify it?
23 MR. GRIMES:
Yes.
You have to know whether you're 24' decreasing design margins to know whether you need NRC 25 approval.
l o
l
32 1
MR. IMBRO:
That's right.
I mean, that type of
!(~)
2 thing is contained in 50.59.
But also, even in Appendix B, V
3 criterion 3 on design control basically requires that you 4
have a documented design basis.
I mean, we feel that there 5
are enough -- that the regulations are really in place, it's i
6 just a question of not being implemented properly.
7 MR. GRIMES:
Everyone is committed to N45.2.11.
8 MR. IMBRO:
2.11, right.
9 MR. SHEWMON:
What you think is a nice idea may or 10 may not cut in the water, what's in the regulations does.
i 11 MR. IMBRO:
That's right.
I think pretty much it 12 is covered in the regulations.
It's just a question of the 13 implementation.
14 MR. SHEWMON:
To bring in an irrelevant comment 15 Machiavelli one time said:
"A prince can rule by love or by 16 fear, fear never fails."
17 MR. CARROLL:
Yes, he did say that.
18 MR. WILKINS:
Do you have any feel for whether the 19 utility could write a contract with an AE that would provide 20 for the AE to deliver this documentation, and if so, what 21 increase in cost?
I' don't mean in absolute dollars, but say 22 relatively speaking.
Just give me a feel -- is it 1 percent 23 of 10 percent, or 50 percent?
24 MR. IMBRO:. I don't know.
I couldn't really put a
)
25 handle on it, even in percentage.
Certainly, if you have
33 i
1 enough money you could buy anything.
(
2 MR. GRIMES:
I think, in the current situation, 3
when you have a bidding process and competition for 4
modifications, that if you make that a condition of the 5
contract, I think people are fairly amenable to doing that.
l 6
If you go back and say I want to now buy from either the 7
NSSS or the AE documentati;n that was -- that's someplace in 8
their files, that hasn't been controlled over the last 20 9
years and you ask them to dig it out and provide it to you l
10 with some assurance that it's -- it represents the plant, 11 then they're going to charge you an arm and a let for that, i
12 and some utilities are going through that process.
13 MR. IMBRO:
One of the reasons we went to General y
14 Electric as a NSSS vendor -- I just kind of picked at random 15 among the 3 was that when we had gone to the utilities, many 16 of the utilities were really somewhat complaining that, gee, 17
.you go to the NSSS vendor and you know, it costs you an arm 18 and a leg to get any information.
Tney're ve.y sensitive to-19 the fact that -
while the NSSS pretty much had the 20 information, they -- they -- and they would let you look at 21 it, they wouldn't let you have it because a lot of it was 22 proprietary.
23 MR. WILKINS:
All right.
24 MR. IMBRO:
Many times we went to an vendor to ask 25 to have some information researched.
It was quite costly.
34 1
In fact, that's why a let of people formed owners groups to 2
pool the utilities together so they can it do it once for 3
several plants.
4 MR. CARROLLt By hiring the NSSS vendor to do the
-5 work.
O MR. IMBRO:
You have no choice.
7 MR. CARROLL:
For an arm and a leg.
8 MR. IMBRO:
Right.
I guess we can turn the 9
presentation over to NUMARC.
10 MR. CARROLLt Am I going to see the words, desigo.
11 basis document and what we talked about yesterday?
12 MR. IMBRO:
I think it's pretty much in there.
13 MR. CARROLL:
I guess that was why I raised the
{
14 question, because I cocidn't find it in there.
15 MR. IMBRO:
I believe that was something that we 16 had even put into Tier I, system design descriptions and 17 design criteria.
I think you'll see it there.
18 MR. CARROLL:
Good afternoon.
19 MR. MARION:
My name is Alex Marion and I'm a 20 Manager-in the Technical Division at NUMARC.
We're gcing to 21 provide you with a brief overview of the design basis 22 program guideline document that we had put together and that 3
Gene Imbro had alluded to in his p:
ttation.
2 24 Tony Pietrangelo will be _
Ang that overview.
25 (Slide.]
35 1
MR. PIETRANGELot Good after.
I'm Tony I
2 Pietrangelo.
I'm also in the Technical Division at NUMARC.
3 Before I get into the presentation on the guidelines, I'd 4
just like to say that it has been a long year and a half 5
working on this document that we're about to publish in the 6
next week or two.
7 We've had several meetings with the staff over the 8
last year and a half to try to get their input into the 9
document.
I'll explain a little bit of wl at motivated us to 10 start this in the first place.
11 I just wanted to say that all the meetings we've 12 had with the staff have been very constructive and 4
}
beneficial, we think, to the final product which I'm here to 13 14 talk to you about today.
15 (Slide.)
16 MR. PIETRANGELO:
Just as an overview of what I'd 17 like to talk to you about; NUMARC established the design 18 basis issues working group that I'll tell you about.
We'll 19 tell you what the working group's goals were in putting L
20 these guidelines together, and then I'll talk to you about 21 the content of the guidelines and what we plan to do with l
22 them.
'23 The working group was-formed in July of-last year.
24-It consists of approximately 21 people, our c'aairman was
\\
25 Dave Hoffman, the Vice President of Nuclear Operations at
~
=.-
. ~..
k' 8I g7 A
1, Consumers Power.
We had 12 utility representatives..These O<
_} );'
2' included vice presidents, engineering directors, program x-3 managers of DBD programs from different utilities.
+
~
4 We had a balance of all the Regions across the 5
U.S. and also, we tried to get a mix of utilities with older 6-vintage' plants, newer plants and all NSSS vendors' plants 7
were also represented on the working group.
We also thought 8
'it was importae' to include representatives from each of the 9
four NSSS vendors, in addition to the four architect 10 engineers who are participants in NUMARC.
We also had a
~11 representative from the Institute of Nuclear Power 12 Operations on the working group.
Q/~N 13 Just a little bit about why NUMARC got involved in l
'Q,)-
14
. design basis issues and formed the working group:
.- 1s )
basically, our membership asked us to get involved.
There
.16 was-a-lot of money being spent on design basis 17 reconstitution programe over the last few years.
I think 18 Gene talked a little bit about that before.
15-There wasn't any consistent guidance in the 20L industry'about what an acceptable framework for a program 12 1 '
would'be, and quite frankly, there-were a lot of people who Vi22' already allocated extensive resources and other utilities n.
23 about to lay-out a lot of resources for a long term program.
24.
They wanted to have some sense of confidence about what was
'fO
\\-)
R20 acceptable and what wasn't a good way to go.
a.
1
.----L.-.-.
-l 37 l
1 I remember one of the remarks made by one of the O;
q_j executives in=the Issues Management Committee at NUMARC was 2-3.
that we only want_.to do this once and we want to do it 4'
right.
Tha'c was the primary motivation for NUMARC taking on s
5
' design basis.
6 (Slide.)
7 MR. PIETRANGELO:
The goals of the working group s.
8 are as follows:
these are right from the mission statement 9
of the working group.
j 10 I think as Gene talked about before, there was 11 some confusion in the industry concerning terminology,
' 12 interpretation of design basis, design control, (r s configuration management.
A lot of-the terms related to i
i 14-design' bases that-we thought we had to get a handle on
~ 15 before we.could move forward with-the guidelines.
16 That was the first objective that the working 17 group tackled.-
Secondly,Jwe wanted to lay out some broad l
18-objectives for desig1 basis programs.
We conducted a survey 19 in September of last year of all the utilities with about 20-
-fifty different applications tbyt ".tilities had identified 21 for-the DBDs that they're producing-through their programs.
22
'From that survey, owe were able to come up with:
23 what we called primary applications for the DBDs which 24 formed the' basis for the objectives that are noted in the er
- 25 document.
Those objectives primarily focus on u
g
38 1
modifications, 50.59 safety reviews, operability 1
2 determinations, tech spec changes and FSAR updates.
1 7
1
.w 3
Those five objectives are kind of the core that 4
are represented in the guidelines that we think form a very 5
good set from which to start with.
Now, that certainly 6
doesn't preclude utilities using the DB0s that they develop 7
in their programs for other applications.
Ne think those 8
five are certainly a good place to start from.
9 The third objective was to develop design basis 10 program guidelines and that kind of encompassrd this whole s
11 set.
The working group also reviewed design control and i
12 configuration management. practices in the industry and that j
jr s H13 -
is touched on in one section of the guidelines.
14:
As Gene got into before, develop positions on 15 discrepancies, operability reportability determinations;
'16 that was identified by the working group members to us in
-17
<the first meeting as a concern of utilities that had already 1 81 Lhad mature programs in place; that we needed to get a very 19:
firm process and positions down on how we wanted to handle 20 this.
- 21 Lastly, we wanted to interface proactively with f
22 the. staff.
We, felt that their input was very important and 23 we wanted to get their assurances also that their concerns
'24 were addressed.in the guidelines.
I think we've done that 25.
to a large extent, and we're at the end of that process now
39 11 and we're moving forward, 2L (Slide.)
3 MR. PIETRANGElo:
The next slide is on the intent.
~4 of the guidelines.
As I said before, we think that the 5
guidelines address all the working group goals that I just 6'
laid out.
In' addition, it provides a level of assurance for 7
those people who have programs in place.
8 We.did a survey recently, just to take a snapshot 9
of where utilities were with those design basis efforts.
I i
10 know in conversations we've had over the last year, it was 11 always1no one knew exactly how many utilities had a program 12
- going,'who were in the pilot phase, who were conaidering a 1
LH The survey L.
program,.who didn't want to do anything at all.
pf s
.131 q
14~
results showed that all utilities had at least assessed a
~
15 need for'a program, and that 90 percent of the stations in 16
.the country had a program completed, in progress, or in the
-17 pilot 1 phase.
So it was a very' extensive voluntary effort by 18 the utilities.
1 19 Those that-had mature programs'in place, we think I
20 the guidelines encompass a. lot of the good practices that l
21
- were identified by the utility members on the working group, f
22 and.will give that level of assurance that we were looking L'
23 for.
YJ 24 In addition, for those utilities that don't have a 25 mature program in place at this point, we think the guidance i'
?
40 provided through the guidelines will be excellent for them 1
/^
(-
2 in planning out their programs.
3 The guidelines are being offered to our members on 4-a voluntary basis to use at their discretion.
We did 5-consider making the guidelines an industry initiative, and 6
actually, we considered that twice in the last six months.
7-The working group's recommendation to NUMARC was S.
that, because of the extensive voluntary effort, and because t
9 the programs are so tailored specifically for the individual
~
10 utilities -- Gene talked a little bit about the differences-11 in plant vintage, vendor -- a lot of utilities bought the
- 12
-cales from.the AEs during the turnovers; others didn't care jjj 13 about them at tnct time -- all sorts of different 14 organizational differences that have an impact on the type 15 of program that a utility wants to tailor -- we didn't think 4
(16.
an initiative was appropriate, firstLbecause the resources 1
1 17-had already been allocated.by utilities, and usually an
'18 initiative is to focus those resources, and that wasn't 19
'necessary.in this case.
L 20 Yes, sir?
R21 MR. SHEWMON:
Would you de*ine your terms?
It 22~
would seem to me your being here'and what you have done on l
523 this is an industry initiative, but I obviously don't I
24 understand the words.
"O 25 MR. PIETRANGELO:
Okay.
The industry initiative
'l 41 1
that I refer to here is a board vote of the NUMARC board of
- 2 directors which would require 80 percent of those directors 3
to approve whatever the initiative encompasses, and that 4
would be binding on all of the members, all right?
5 This was, yes, an initiative in that the working 6
group was formed, but not a board initiative that everyone 7
voted on.
8 MR. SHEWMoN:
I have heard that before.
Thanks.
9 MR. PIETRANGELO:
Okay.
1 10
-(Slide.)
.11 MR. PIETRANGELO:
Okay.
Now, on the guidelines 1*
themselves, just'a brief outline of -- and I believe there
(;(~si 13-is a copy available to you -- the intro, a section G.
L' (
.14 -
definitions, the-intent of DBDs.
Developing DBDs is kind of-4
-15 a lessons learned session.
A lot of this information was 16' obtained from INPO that they compiled during their 17'
' assistance visits and evaluations.
It has-a lot of good.
-18 practices, if you will, on how to administer a DBD program 4
19 and more, what pitfalls to look out for when you're putting 20 a program together.
12 1 What-we think is one of the key sections is 22' addressing discrepancies.
I have another slide that 23 addresses that'more specifically.
Validation maintenance
~24 and control -- we felt this was important enough such that
..D l _)
l!S we needed another section in the guidelines.
Certainly, if s
pw 42 r-1.
you're going.to allocate that much resources to this
)
2 program, you want to make sure that you maintain a credible 3
basis for the application of the documents.
l 4
A final section on integration with design control 5
-and configuration management.
It's very important, we
-6 think, that utilities use the DBDs they produce in their 7
programs in their existing design control and CM practices, 8
and we touch on that in that one section.
9 Finally, several appendices to give a lot of l
10 examples of sources of DBD information, supporting 11 information,. applications, and also additional information 12 to consider to be scoped into a DBD.
- fs
.13 (Slide.)
(
\\
14 MR. PIETRANGELO:
15 The key points,'we feel, that are contained in the 16l document,.first of all is to focus the interpretation of 17 design basis under 10CFR50.2 definition.
Basically, that L18 touches on information that identifies specific functions 19-for a structure system or component, and also specific 20 values or ranges of values that bound the design.
.21 That's what the. utility is responsible for.
They 22' have to know that information.
Without compiling that-23 information,-and' organizing and understanding it, you don't 24-have a basis for any of the objectives that are laid out in
)
25 the guidelines.
l 43 1-I think, as Gene touched on before, and I think l
'2
. Chairman Michelson also touched on in his question, you have 3
to~know the why information, also.
That interpretive step 4'
is one of the things we think is a major focus of the 5
guidelines'.
Getting that understanding of why the setpoint' 6
is set at 750 pounds and not at 700 pounds, that kind of 7
.information that supports the design basis is really the y
.8 key.'
Not surprisingly, that is the information that most 9
utilities are having trouble recolf.ecting.
10 Ofttimes, you have to go back to the design 11 engineers, if they are still around, and many of the 12 utilities;have-compiled that information through interviews-13 with'those people, have been in correspondence and meeting il l 14
' minutes from meetings 20 years ago.
L15 A lot-of'that good why information is contained in
,116' those. kinds of sources, and not-in a.cale or some document r
17 you can really get your hands On that's in a file and filed a
1 18 neatly, but in an old engineer's file that he kept at his-
'19 desk.
A lotlof the good information has been from those
- 20I sources, the utilities have found.-
l Third, the other key point we wanted to make in i
21' 22 the guidelines was that.the program should enhance your.
23 existing design control and CM practices.
One of the things 24-we found, and this gets back to the terminology question, a
'25 lot of people were mixing terminology of design basis with
. ~ -.
44 o
'l design control and configuration management.
l
[,( )
- 2 The design bases and the DBDs that collate that L
'3 information is something that you can get your hands around, 4
that you can touch, you can feel, and that you can organize, L
5 whereas the design control and CM practices have been around 6
since day one, okay?
Those are existing practices at l.
7=
utilities.
Whether you call them that or not, you've been
/
8-doing that since your plant went commercial.
9 One of the things we think the programs are aimed 10' at is enhancing the input to those processes through 11 collating the design basis information and supporting 12 information11n DBD, and we think we'll see a big benefit in t
L 13 these practices.
i
't,n' 11 4 (Slide.)
R 15 MR.-PIETRANGELD:
The other key area was on 16' addressing discrepancies, and I. don't want to focus too much 17 on what Gene has mentioned previously, but the focus of the 18-section that we have in the guidelines-is on a managed j
'19 approach.
20 Several utilities had gone through kind of a 21 crisis atmosphere'in trying to address discrepancies that 22 came out of their reviews during their design basis efforts.
23 We feel that that managed approach -- and I'll' show you a 24 slide in a minute that lays out the process of what we think O
(j-25 the managed approach is all about -- entails.
45 1-The presumption of' operability is essentially the 9,-L
(
i 2
same thing as-Gene talked about and the premise of 4
3-operability.
If you have broad engineering experience and 4
judgment and other sources of information that give you a 5
good feeling about the operability of a structure system or a
6 component, just because you don't have a piece of paper such 7
as a calc or evaluation gives you that airtight, yes, this t
8 is operable determination, doesn't mean that you shut down 9
the, plant and wait 'til you get the~information.
We think 10-you can rely on that broad engineering-experience and i
i
,11 judgment in those types of cases.
j;
.12 Also, this section contains a subsection on
,a 13 simplifying reportability determinations in the LER process, 14
.I'think Gene touched on that already.
15 And we did propose a modification policy change --
-16 modification to enforcement policy.
Originally, that was ij
,17
- part'of the guidelines.
We ended up taking that out and l
18 sending a separate letter to the staff requesting
. )
u 19
-consideration for that change.
And, essentially, it was 42 0
.trying to remove it.
[
21L Well, we thought it was disincentive that if a
- t
-22 utility, through a self-initiated effort, uncovers a 23 discrepancy from possibly several. years ago, takes
'I 24 appropriate corrective action and satisfies all the criteria 25 in the exercise of discretion policy that's laid out now.
l 46 1
1 We didn't think it was appropriate to nail the utility also
.f}
O _/
2 with a notice of violation in those cases.
s 3
So, basically, what our request does is expands 4
the scope of the exercise of discretion.
5 (Slide.]
~6-Finally, I just want to talk a little bit about m,
i
.7 this process-for managing discrepancies.
8 The first box is the discrepancy determination.
9 And, basically, this is kind of a prescreen such that we L
10 wanted to draw a distinction between open items and l'1 discrepancies.
There are many questions raised during the i
12 course of:a design basis program that come up.
And we don't q}13-suggest that all of'those questions get run through this l
H l
14
- process, y
15 What we think, though, is'that when there is a 16 Leonfirmed discrepancy that has a potential for impacting 17
- plant operation that it be elevated into this process.
At 18 that point, we have a screen called safety concern where J19
'three basic questions are asked to determine whether you' 20-
.ought to1 proceed with formal operability and reportability 21 evaluations.
22' Following that, a decision block as to if you do 23.
+have something that is an operability issue you would take
'l 24 the appropriate toch spec action.
If not, you would w
25
- complete the system DBD.-
47 l
1 Same with reportability.
And then if you did have y( %).
2 a reportable' issue you'd file your IER and complete the
- 3 activity.
If not, you'd just go right on to the complete 4
activity block.
S What that block does is allows that process of 6
collating the information, and for most utilities this is a 7
three cut four month process where they'll get together with 8-their'NSSS vendor and AE, go back through all the old files, e
g
.9 do their interviews, get all that information together.
In 1:
h 10 that process'is where some of these discrepancies come up.
11-What we do here in this block is allow them to S12 complete that activity and get what they think is that whole 1;
l ' i.(~)
set of information on the system that they originally 13 s
[~V i
14 sought, then go to a final evaluation block where all that' 15:
information is reviewed.
?
.16 Any operability issues, reportability issues are L
l 17=
also reviewed cumulatively so that any synergistic effects i:',
18'
- in the system are looked at in a comprehensive fashion.
T19j Then-you would' proceed to the closecut of whatever'the 12 0 discrepancy.
21 We think this process is good in that it shows a 22 structure for addressing these problems as they come up, and 23
' if they-are significant safety concerns then they're.
r 24' evaluated by the appropriate people in an appropriate time
'fi ss_)
25 frame.
48-11 And we think this process is terrific for these
-2 programs.
And I think it's pretty much what people are 3
already'following in their day to day plant operations also.
4 That's all I have to say today.
5 MR. CARROLL:
Can we go off the record for just a 6
second?
7 MR. PIETRANGELO:
Sure.
8
'[Brief recess.)
9 MR. CARROLL:
Back on the record.
10 MR. SHEWMON:
What is the definition of a 11
< discrepancy on your last slide -- design basis discrepancy.
J12L This is --
t i
13' MR. PIETRANGELO:
A discrepancy is an item that-
.14 has been' confirmed discrepant in that you have done some 15t
. evaluation of it.already.
Let's say two documents don't 16 match or give the same value for a particular parameter.
117.
MR. WILKINS:
It might be helpful if'you could 18' give us an example of a discrepant.
19 MR.-PIETRANGELO:
Well, let's say you're 20 researching to do your DBD and on two source documents two c 21
-different-values are given, okay,.for the same parameter.
.i:
22.
Okay?
That would be a discrepancy.
Now is it. safety 23 significant?
Well, if one of the discrepancies, let's say, 24
.was above a tech spec value, then I'd say, yeah, that's 9
-25 potentially safety significant and you would elevate it into z
I
E:
49 1
that process.
)
L But if there was a mismatch in the values but they 2
3-
. wore both within, let's say, some tech spec value, then I z
4 wouldn't consider that safety significant and wouldn't 5
evaluate it into that process.
6 It could be mismatches with hardware and software T
7 also that you'd find when you were doing the validation of-8_
the DBD in the field later.
9 So it could be from a number of different sources, l
10-actually.
1 MR. CARROLL:
Looking at your definitione, it 1
12 looks like you've gotten a little circular here.
Under open j
13 items you're saying that there are things that are potential i
'14 discrepancies.
And under discrepancies you're saying, those T
open items-are confirmed discrepant.
15 uh
-l f
16 MR. PIETRANGELD:
Yeah.
And what that is is I 17l think open items is very broad.
One working group member
=
181
' defined-it as anything not closed.- Okay?
So any question 19
.that any engineer had could be an open item that someone 20 would want to document, but you would not necessarily want 21' to elevate'it such that you're doing formal operability and 22 reportability evaluations on it.
23 MR. CARROLL: 'When you see one you know it.
24 MR. PIETRANGELO:
Exactly.
And that's been 25 people's experience.
I m
5 50
-11 MR. CARROLL:. Any questions?
h2 (No response.)
3-MR. PIETRANGELO:
Thank you.
4-MR. MARION:
This is Alex Marion again.
I would 5
just like to indicate that we are moving forward with
.6 holding two industry workshops on the guideline and we've
.7-invited the NRC to participate in those workshops and they
- 8 have_ graciously accepted our invitation.
We're planning to 9.
conduct them.the last week of November and the first week of 10, December.
11
- We expect our activities to be reasonably 12 completed.after the December workshop.
(
13 MR. WILKINS:
Where?
14.
MR. MARION:
Baltimore in November, and New L15 Orleans, for some reason or other, in December.
We felt we 16~
ought-to.get'a couple of bennies out of the effort, to be 17 honest with you.
18 MR. CARROLL:
Does the staff have anything they
-195 want to say in closing?
- 20 MR. GRIMES:
No.
I think it's been a useful-21
' effort.- At lot of. times on these difficult questions, the-22
~ process is;most of the-benefit and'I'think both the staff 23 and the industry have learned a lot just by the process of 24 struggling _with the questions over the last couple of years.
25 MR. CARROLL:
For the full committee on Thursday
51
-1 morning, 10:45 to 11:15, a half hour, I guess the plan is --
( )
-2 oh, no, that's Imvel of Detail.
3-Sorry, it's 45 minutes, 3:30 to 4:15 on Friday.
I 4
guess I'm one of three subcommittee _ chairmen to report.
Do 5
you feel that we need either the staff or NUMARC, or should 6
I just make a brief report on what we heard about?
7 MR. WILKINS:
I think you can say that the NUMARC 8'
document is about to hit the street.
9 MR. GRIMES:
The staff sees no reason to make a 10 presentation to_the full _ committee.
I think you can 11 characterize it well'.
12 MR. CARROLL:
You just don't like to expose i
13 lyourself, right?
14-HMR. GRIMES:
They told me ROTC to not buzz 15l anyplace and don't buzz anyplace twice.
16-(Laughter.]
17 MR. CARROLL:
Okay, we'll' handle it that way.
I'd 18' like to thank the staff of NUMARC-for_their informative
.19' presentations.
With that, we shall adjourn.
20.
.(Whereupon, at 2:30 p.m., the Subcommittee was 21:
adjourned.]
22-23' 24 25-
' +
l REPORTER'S CERTIFICATE This is to certify that the attached-proceed-ings before the United States Nuclear Regulatory Commission in the matter of:
NAME OF PROCEEDING: Plant Operation DOCKET NUMBER:
PLACE OF PROCEEDING: Be'hesda, Maryland vere held as herein appears, and that this is the original transcript thereof for the file of the United-States Nuclear Regulatory Commission
'taken by me and thereafter reduced to typewriting by me or under the direction of the court report-1rg-company, and that the transcript is a true arid accurate record of the foregoing proceedings.
_./
y.-- - m O
f L4nw J JO g
/
Official Reporter Ann Riley & Associates, Ltd.
y M
1
- 0 i
1
h i,I lOJ.
~
ACRS SUBCOMMITTEE ON PLANY 091 rations NOVEMBER 1, 1990 NUMARC
. DESIGN BASIS
. 6g PROGRAM-GUIDELINES e
'(,
i TONY-PIETRANGELO l:p,
SENIOR PROJECT MANAGER
- NUMARC,: TECHNICAL DIVISION O
Y g
OVERVIEW o
NUMARC DBI WORKING Gnoup o
DBI: WORKING GROUP GOALS e
o' DESIGN BASIS PROGRAM GUIDELINES
- Q; 4
s k
-1 t..
I 1
9 2
1^
NUMARC DESIGN BASIS-ISSUES' WORKING GROUP g
CHAIRMAN:-
DAVID HOFFMAN VP, NUCLEAR OPERATIONS r
CONSUMERS POWER-12 UTILITIES REPRESENTING ALL NRC REGIONS 4LNSSSVENDORS:
WESTINGHOUSE BABCOCK & WILCOX
' GENERAL ELECTRIC COMBUSTION ENGINEERING e
- 4JA/ES:
BECHTEL FLuoP.-DANIEL UNITEo ENGINEERS STONE & WEBSTER
'\\
INPO 3
g 9
m D
DBI WORKING GROUP GOALS o
DEVELOP CLEAR TERMINOLOGY
- O IDENTIFY OBJECTIVES FOR DB PROGRAMS O
DEVELOP DESIGN BASIS PROGRAM GUIDELINES o
REVIEW DESIGN CONTROL AND CONFIGURATION MANAGEMENT PRACTICES LOL o-DEVELOP POSITIONS ON DISCREPANCY-DISPOSITION,_ OPERABILITY AND REPORTABILITY DETERMINATIONS 0-INTERFACE PROACTIVELY WITH NRC To ADDRESS INDUSTRY.AND REGULATORY CONCERNS.
l 9
4
O e
15 DESIGN BASIS PROGRAM GUIDELINES INTENT o
ADDRESS ALL WORKING GROUP GOALS 0-PROVIDE-LEVEL OF ASSURANCE FOR-EXISTING > PROGRAMS o
' PROVIDE: GUIDANCE FOR THOSE CONSIDERING PROGRAMS Oi o
FOR UTILITY USE ON A-VOLUNTARY BASIS o
NOT AN-INDUSTRY INITIATIVE g
5
D DESIGN-BASIS PROGRAM GUIDELINES OUTLINE-LO INTRODUCTION o
DEFINITIONS
!r i:
OL INTENT OF DBDS L
q L
0' DEVELOPING DBDS-1 0-ADDRESSING DISCREPANCIES u
L 0
' VALIDATION,-MAINTENANCE 1AND CONTROL 0
INTEGRATION WITH DESIGN CONTROL AND m
CONFIGURATION MANAGEMENT o
0 APPENDICES O!
6
i D,
DESIGN BASIS PROGRAM GUIDELINES KEY POINTS
- O:
FOCUS INTERPRETATION OF " DESIGN BASES" PER 100FR50.2 DEFINITION:
~
' SPECIFIC FUNCTIONS
. SPECIFIC VALUES THAT BOUND DESIGN
^
Q o-CAPTURE WHY" INFORMATION THAT SUPPORTS
+
- DESIGN-BASES AND-UTILITY SPECIFIC 4
PROGRAM OBJECTIVES 0:
DESIGN BASIS PROGRAM SHOULD ENHANCE EXISTING DESIGN CONTROL-AND CONFIGURATION-MANAGEMENT PRACTICES J
':[
\\
4
6 6
DESIGN BASIS PROGRAM GUIDELINES e
r
- ADDRESSING DISCREPANCIES u
O MANAGED APPROACH O-
- PRESUMPTION OF OPERABILITY OL SIMPLIFYEREPORTABILITY DETERMINATIONS AND;LER' PROCESS O
propose MODIFICATION TO-NRC ENFORCEMENT PDLICY-
\\ '.
4 8
2"^
~
_l
- i; _ -*
7*'.
LO; O
~
~
- O
~
^
t 1
Discrepancy FIGURE 2:
l Design Basis Discrepancy Demnnination SWety N
Resolution Process Concem?
j i
' l l
Operability
.Y' Floportability l
l Evaluation Evaluelion I
1 N
N Reponstdby Operatsty issue?
leeue?
j Y
-Y
, e
, r I
Take Tech Spec Complete Report orother action Design Basis Activity bNRC
-1 l
Final Evaluation l
1 I
ck-ut I
8 ein, =
8 7
4l'r' k
W M
att gQ 2.
M O
E
'H H
to E
O *C s-W CE J
'M ~E 4lE2 3
' W D
ECE m
v wWQ o
g
. O.
M LL C3 O
>=
>20 E
GA
<~
E t.D WWE
~
E J A.
.O M
WUC
- H W
CQU Q
.Q DE W
- H o
H E
M u) aC E
D Ov W
E i;
}(
4
,y...
~
?Oh ~ b m
o O
NRC TEAM INSPECTIONS- (SSFI, SS0MI) HAVE IDENTIFIED T!!AT:-
s (1)
MODIFICATIONS HAVE BEEN MADE WITHOUT SUFFICIENT ENGINEERING BASIS THAT HAVE COMPROMISED SAFETY SYSTEM-FUNCTIONALITY.
. 2)
HISSING OR UNRETRIEVABLE DESIGN DOCUMENTATION APPEARS
(
TO'BE A ROOT CAUSE OF Ti1ESE PROBLEPS AS A RESULT MANY UTILITIES HAVE BEGUN DESIGN BASES RECONSTITUTIO
~
PROGRAFS 2.
N O
-*ZHM m
>- W LZ 0
h O.J QW
-J
&%G E$&
W E
6 OO WHU W
E Z
W W
UCWb 5WM Q
ZEE o.
U W ::D M
- WO k
oW$
--E M
E o
MW O
MW E
E W O
W%
M W
W Z
O W
WWE g
M QCZ Er W
&4 -
5 y
E e
z
=
o e
" 0.; b
,~
>
M ::D 8 $ 6.-. 12 am
.a
- D L 5.-. b p f m==
V) MWK W H A ma:
A M *-* Q-
+ 1, 4
4
O O
O l-CATEGORIES OF DESIGN DOCUMEKIS DESIGN INPUT DOCUMENTS.
DESIGN ANALYSES DESIGN OUTPUT DOCUMENTS CALCULATIONS DRAWINGS NRC REGULATIONS EVALUATIONS PURCHASE SPECS STD. REVIEW PLAN TRADE-0FF/0PTIMIZATION "Q" LIST I
REG. GUIDES DESIGN INTES" ICE STUDIES INDUSTRY STD's.
DOClHENTS
-ETC.
DESIGN PROCEDURES SETPOINT LIST (A/E - NSSS SUPPLIER, ETC.)
VALVE EIST VENDOR PERFORMANCE REQUIREMENTS ETC.
ETC.
4.
O O
O THE_ REGULATORY DESIGN BASIS IS A SUBSET OF THE ENGINEERING DESIGN SASIS REGULATORY DESIGN EASIS (10 CFR 50.2)
ENGINEERING DESIGN BASIS o
NRC REGULATIONS o
REGULATORY DESIGN BASIS o TECH SPECS o
NON SAFETY-RELATED CRITERIA FOR STRUCTURES o SER SYSTEMS, a COMPONENTS PERFORMANCE o
LICENSEE COMMITMENTS o
DOCUMENTED "G00D ENGINEERING PRACTICE" FSAR NEMA STDs TEMA STDs LERS ISA STDs ASHRAE STDs i
CORRESPONDENCE liYDRAULIC INSTITUTE STDs A/E NSSS SUPPLIER DESIGN PROCEDURES ETC.
,1 5.
L.
O O
O l'
WHY ARE DESIGN DOCUMENTS NECESSARY?
i l
FORM THE BASIS FOR FUTURE PLANT MODIFICATIONS QUANTIFY DESIGN MARGINS AND DEFINE OPERATING ENVELOPE
- BASIS FOR 50.59 EVALUATIONS FORM A LIVING RECORD OF THE AS-CONFIGURED PLANT PROVIDE A TECHNICAL BASIS FOR CONTINUED OPERATION l
(INCLUDING LIFE EXTENSION)
I f
i I
t i
6.
~
e e,. -.. ~ +, - ~
O
.O O
STAFF ACTIONS o
PERFORM LIMITED INDUSTRY SURVEY BY VISITING 6 LICENSEES AND 1 NSSS VENDOR o
COLLECT INFORMATION DESIGN DOCUMENT AVAILABILITY CHANGE CONTROL PROCESS INTERFACE BETWEEN ENGINEdRING, MAINTENANCE, OPERATIONS, TRAINING AND LICENSING i
UTILITY-INITIATED DESIGN BASIS DOCUMENT RECONSTITUTION PROGRAMS 7.
~
O O
.O STAFF ACTIONS-(CON'T)
ISSUE NUREG TO PROVIDE INFORMATION ON GOOD PRACTICE IN THE o
FOLLOWING AREAS:
TYPES OF DESIGN DOCUMENTS THAT SHOULD BE CONTROLLED AND MAINTAINED AS-FIGURED THE CIRCUMSTANCES AND TIMEFRAME THAT DESIGN DOCUMENT.i SHOULD BE RECREATED, IF AT ALL EVALUATION OF. STRENGTHS AND WEAKNESSES OF UTILITY ~ INITIAT BASIS DOCUMENT RECONSTITUTION PROGRAMS CURRENT PRACTICES IN DESIGN CONTROL / CONFIGURATION MANAGEE 8.
U l
~
~
O o
o LICENSEES SURVEYED CAROLINA POWER AND LIGilT-H.B. ROBINSON - 2 o
PENNSYLVANIA POWER AND Ll6HT SUSQUEHANNA o
PACIFIC GAS AND ELECTRIC DIABLO CANYON o
FT. CALHOUN CMAHA PUBLIC POWER DISTRICT o
-FLORIDA POWER CORPORATION CRYSTAL RIVER 3 o
FLORIDA POWER AND LIGHT TURKEY POINT 3 AND 4 o
NSSS VENDORS SURVEYED _
o GENERAL ELECTRIC 9.
O O
O LEVEL OF DESIGN DOCUMENTATION o
ESSENTIAL DESIGN DOCUMENTS o
SUFFICIENT DESIGN DOCUMENTATION SHOULD BE AVAILABLE FOR FUTURE PLANT MODIFICATIONS TO SUPPORT THE FINAL AS-CONFIGURED DESIGN OF THE SYSTEM BEING MODIFIED o
THIS MAY REQUIRE THE REGENERATION OF MISSING DOCUMENTATION 4
(
(
10.
O O
O
?
DESIGN AUTHORITY I
I AFTER THE 0/L, THE OPERATING ORGANIZATION GENERALLY DRIVES MODIFICATIONS AND MAINTENANCE, HOWEVER, THE ENGINEERING ORGANIZAT10h SHOULD BE RESPONSIBLE FOR:
MAINTAINING Tile PLANT DESIGN BASES ASSURING DESIGN OUTPUT DOCUMENTS REFLECT THE CURRENT' DESIGN
~
BASES ASSURING DESIGN OUTPUT REQUIREMENTS FOR PLANNED MODIFICATIONS I
ARE COORDINATED WITH TliE PLANT STAFF.
4 l
i i
1 it.
i-
4-w' v
....m
~
O O
O SURVEY OBSERVATIGNS l
0 DESIGN DOCUMENT RECONSTITUION PROGRAMS ALL UTILITIES SHOULD EVALUATE THE NEED TO INITIATE A DESIGN DOCUTIENT RECONSTITUTION PROGRAM (DDR)
NEED FOR DDR PROGRAM PROP 0RTIONAL TO FACILITY AGE A DESIGN DOCUMENT RECONSTITUTION PROGRAM SHOULD MEET UNIQUE UTILITY NEEDS NEED FOR UTILITY STAFF INVOLVEMENT IN DDR PROGRAfG 1
NEED FOR STRONGER IH-HOUSE ENGINEERING CAPABILITIES DESIGN BASIS DOCUMENTS (DBDs) SHOULD BE CONTROLLED DOCUMENTS AND MAINTAINED AS-BUILT DBDs PROVIDE A CENTRALIZED LOCATION FOR DESIGN INFORMATION 9
12.
4 i
== -
,3
(
~
V U
SURVEY OBSERVATIONS (Con'T) o NEED FOR TF1tPLATE APPROACH o
RECONSTITUTION OF DESIGN BASES ALONE MAY BE INSUFFICIENT.
CONSIDERATION SHOULD BE GIVEN TO REGENERATION OF SUPPORTING CALCULATIONS o
NEED FOR A DEFINED PRIORITIZATION METHODOLOGY TO REGENERATE MISSING DESIGN DOCUMENTS l
0 CONCEPT OF ESSENTIAL DOCUMENTS IS NECESSARY TO REQUIRE REGENERATION OF bJe SUPPORTING OPERATIONAL LIMITS o
NEED FOR FIELD VALIDATIbi.
DESIGN BASES DOCUMENTS o
NEED FOR TECHNICAL REVIEWS OF DESIGN DOCUMENTS l
(
i i
13.
l
}
t i
OPERABILITY, REPORTABILITY, ENFORCEMENT-l 0
OPERABILITY DETERMINATIONS NEED TO MAKE OPERABILITY DECISIONS IN A Til;E FRAliE COMMENSURATE WITH SAFETY SIGNIFICANCE 1.
PREMISE OF OPERABILITY CONTINUOUS DECISION PROCESS 0
REPORTABILITY NO CHANGE IN NRC REPORTING REQUIREMENTS PREPARATION OF FINAL EVALUATION OF LERs FOR EACil SYSTEM TO IDENTIFY CORRECTIVE ACTIONS 0
ENFORCEMENT POLICY ENCOURAGES UTILITY-INTIATED PROGRAMS t
1
?
3 14.
1 i
.. _ -