ML18025B924
| ML18025B924 | |
| Person / Time | |
|---|---|
| Issue date: | 01/24/2018 |
| From: | Office of Nuclear Reactor Regulation |
| To: | |
| References | |
| RIS-02-022, S01 DRF | |
| Download: ML18025B924 (72) | |
See also: RIS 2002-22
Text
Summary of Comments
on 2018-01-23
Draft RIS_KS.pdf
This page contains
no comments
This page contains
no comments
1234
Page: 3Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:06:34
PM In the sentence
directly
before this one, the limitation
regarding
not providing
new guidance
is restricted
to RPS and ESF. But in this sentence
that limitation
is extended
to all SSCs. This contradicts
subsequent
sections
of this RIS which provide new CCF guidance
for other non-RPS/ESF
SSCs. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/23/2018
10:39:52
PM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
in most FSARs, maybe all. So CCF due to a design flaw is considered
in most, maybe all, FSARs. Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:02:09 AM
12
Page: 4Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:07:45
PM The first paragraph
on Page 3 says this RIS is not applicable
to RPS/ESF.
But this paragraph
implies it would not be applicable
to any equipment
of equal or greater importance
to RPS/ESF.
Importance
can be determined
by the PRA. Equipment
of equal or greater importance
would typically
include load sequencers,
and accident
monitoring
instrumentation
and controls
for manual actions credited
in the TAA. So the original
statement
that says this RIS is not applicable
to RPS and ESFAS should be expanded
to encompass
these additional
systems. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:06:19 AM
1234
Page: 5Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:08:20
PM We typically
view "failure
to perform"
as "no function
at all". But equally important
is performing
a design function
erroneously.
This is too often forgotten
by digital designers.
It should be clearly stated. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:15:39 AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
9:17:29 AM A failure of shared resources
among safety control functions
can also introduce
unanalyzed
malfunctions.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:13:15 AM
12
Page: 6Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:01:37
AM SECY 93-087 and BTP 7-19 constitute
current NRC policy on digital CCF. The current policy does not allow a conclusion
that the likelihood
of a CCF is sufficiently
low to require no further consideration
based on these qualitative
factors alone. The current policy is clear that these qualitative
factors facilitate
a conclusion
that the CCF is beyond design basis, but not that it requires
no further consideration.
Another way of looking at this is that the current policy is that qualitative
factors do not allow a conclusion
that the likelihood
is comparable
to other sources of CCF that are not considered
in the FSAR. How can a RIS be used to change previous
NRC policy. I have heard some people say that the current NRC policy is only applicable
to new plants. If that is true, which I don't believe it is, then how can the NRC createa new policy for operating
plants that is different
than for new plants. This directly
contradicts
the commissioners
direction
in (SRM)-SECY-16-0070
that the guidance
for new plants and operating
plants should be the same. Number: 2 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:10:01
PM Dave, You told me that "sufficiently
low" could only be reached with 4 factors,
the fourth being an evaluation
of the "what if" malfunction
results.
This contradicts
your explanation
of this RIS. If your interpretation
is confused,
the industry's
interpretation
is also going to be confused.
This page contains
no comments
This page contains
no comments
1234
Page: 9Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
9:38:55 AM Licensees
will often conduct these evaluations
prior to investing
in revised design/analysis
documentation.
Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:37:49 AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
9:40:45 AM Dave, This does not say that a failure must be postulated.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:40:15 AM
12
Page: 10Number: 1 Author: KenSc Subject:
Highlight
Date: 01/23/2018
10:53:30
PM Number: 2 Author: KenSc Subject:
Sticky Note Date: 01/23/2018
10:53:57
PM No postulation
of CCF.
123456
Page: 11Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
9:47:22 AM This is technically
incorrect.
Single failures,
by definition
are random, non-systematic
failures.
An increase
in the likelihood
of a single failure,
does lower system availability,
but it does not increase
the likelihood
of a CCF. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
9:44:37 AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:18:38
AM Should be NEI 01-01 Section 4.4.6. Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:18:44
AM Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:04:39
AM This note just adds confusion
because it says that if a failure is not credible
but not sufficiently
low likelihood
it must be considered.
Number: 6 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:03:46
123456
Page: 12Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:12:33
AM This contradicts
previous
statements
in this RIS and in NEI 01-01 which state to require no further consideration
in 50.59, the failure likelihood
must be "comparable
to other common cause failures
that are not considered
in the UFSAR". Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:12:30
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:07:57
AM Yes, but the sentence
above says that even if you have not reached the "sufficiently
low" threshold,
there are no new accidents
introduced
unless the failure is "as likely" as other failures
assumed in the FSAR. This is quite confusing.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:05:54
AM Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:11:38
AM This contradicts
previous
statements
in this RIS and in NEI 01-01 which state to require no further consideration
in 50.59, the failure likelihood
must be "comparable
to other common cause failures
that are not considered
in the UFSAR". Number: 6 Author: KenSc Subject:
Highlight
Date: 01/23/2018
10:57:32
12345678910
Page: 13Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:20:03
AM This contradicts
NEI 01-01 which says to require no further consideration
the failure likelihood
must be "comparable
to other common cause failures
that are not considered
in the UFSAR", not as likely as those that are considered.
Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:13:32
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:21:57
AM Needs to also include ways of erroneous
performance.
You can argue that "failure"
encompasses
"erroneous"
but erroneous
is too often overlooked
by digital designers.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/23/2018
10:58:55
PM Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:27:10
AM This should say "which ones that are not as unlikely
as failures
not considered
in the FSAR" or "which one whose likelihood
is not comparable
to other common cause failures
that are not considered
in the UFSAR." Number: 6 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:22:20
AM Number: 7 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:53:43
AM "as likely as those described
in the FSAR" contradicts
"comparable
to other common cause failures
that are not considered
in the UFSAR", which is your definition
of "sufficiently
low". These are two different
thresholds.
So it is not clear when Steps 3-5 are needed. This RIS is supposed
to bring clarity to the 50.59 issue, not more ambiguity.
Number: 8 Author: KenSc Subject:
Highlight
Date: 01/23/2018
11:00:26
PM Number: 9 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:33:03
AM Clarify that "end result" means "plant level". Number: 10 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:28:29
12345678910111213141516171819
Page: 14Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:49:34
AM This is new NRC policy that clearly contradicts
the quote in this paragraph
from NEI 01-01, which is previously
endorsed
by NRC. It is not clarification
of previous
policy. It also contradicts
SECY 93-087 and BTP 7-19. A RIS cannot change previous
NRC policy. Regardless,
"best estimate"
methods are used in most, maybe all, FSARs for ATWS, SBO and fire. So they are used in the FSAR, therefore
even with this new policy they can be used to evaluate
CCFs when the CCF is considered
beyond design basis (i.e., significantly
less likely than other malfunctions
considered
in design basis events). Number: 2 Author: KenSc Subject:
Highlight
Date: 01/23/2018
11:02:45
PM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:33:15
AM Clarify that "end result" means "plant level". Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:31:39
AM Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:34:04
AM These are failure modes or component
level effects.
They are not the "end result" Number: 6 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:34:02
AM Number: 7 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:44:51
AM What does it mean to be "bounded".
This RIS needs to provide guidance,
because this is a particular
area for frequent
industry
inconsistency.
Number: 8 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:34:56
AM Clarify that "end result" means "plant level". Number: 9 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:34:29
AM Number: 10 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:44:57
AM Number: 11 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:47:18
AM This is not clear. All design functions
are assigned
at the system level. But the effects of system level failures
are determined
at the plant level. Clarity is needed here because this is another area of frequent
industry
inconsistency.
Number: 12 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:46:06
AM Number: 13 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:47:45
AM define "bounded"
Number: 14 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:47:34
AM Number: 15 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:48:50
AM "results"
appears to have two different
meanings.
This needs clarification.
Number: 16 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:48:19
AM Number: 17 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:48:24
AM Number: 18 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:52:10
AM "bounded"
is used in three quotes on this page. But it is never defined here or in NEI 01-01. A definition
is clearly needed. Number: 19 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:51:10
12
Page: 15Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
10:58:08
AM The same software
in different
systems could be considered
a "shared resource".
So change to "shared hardware
resource".
Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:56:17
12345678
Page: 16Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:00:58
AM This contradicts
previous
sections
which say that the malfunction
must be analyzed
only if the likelihood
is not "sufficiently
low" based on a qualitative
assessment.
Here you say that analysis
is needed to reach the "sufficiently
low" threshold.
This is quite confusing.
Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
10:59:25
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:01:26
AM Very unclear.
See previous
comments.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:01:11
AM Very Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:04:42
AM Even if you hardwire
a signal from a digital device, the digital device itself can create an erroneous
signal that could adversely
affect RPS/ESF.
Digital data communication
creates an additional
communication
independence
vulnerability.
But it has no effect (positive
or negative)
on functional
independence.
Number: 6 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:02:46
AM Number: 7 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:07:50
AM Per previous
NRC policy, all of these attributes
facilitate
a conclusion
of sufficiently
low likelihood
to be analyzed
using "best estimate"
methods.
Not sufficiently
low to require no further consideration.
This RIS is changing
NRC policy. Number: 8 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:07:41
This page contains
no comments
123
Page: 18Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:10:25
AM Limiting
and mitigating
do not reduce the likelihood
of the failure. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:09:58
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:12:29
AM This paragraph
is not related to design attributes
that reduce the likelihood
of failure.
It is about tolerating
the failure.
This paragraph
should be deleted or moved.
This page contains
no comments
This page contains
no comments
12
Page: 21Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:18:10
AM Clarify that this refers to functional
diversity.
Implementation
diversity
is not required
in the protection
system by 10CFR Part 50 Appendix
A. Implementation
diversity
is only required
by 50.62 for ATWS, which is a beyond design basis event for which "best estimate"
methods are permitted.
Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:16:14
This page contains
no comments
This page contains
no comments
This page contains
no comments
1234
Page: 25Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:27:04
AM This contradicts
your definition
of "sufficiently
low" which requires
the failure likelihood
to be comparable
to failures
not considered
in the FSAR". Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:26:09
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:29:00
AM The ability to mitigate
the malfunction
is completely
different
than the determination
of likelihood.
Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:27:52
12
Page: 26Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:31:46
AM Clarify that this means risk comparable
to other failures
that are not considered
in the FSAR and distinguish
this from risks that do not reach this level and therefore
require further analysis
of the plant level effects. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:30:54
This page contains
no comments
12
Page: 28Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:36:46
AM BTP 7-19 says a D3 analysis
is required
for "safety systems"
not just protection
systems.
A RIS cannot change current Staff policy. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:36:08
This page contains
no comments
123456
Page: 30Number: 1 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:39:34
AM Number: 2 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:39:13
AM These other attributes
can be used when accompanied
by Staff review. Now you are changing
the Staff policy to allow these other attributes
to be used withoutStaff review and without additional
endorsed
Staff guidance.
Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:42:46
AM You are making a statement
with inadequate
justification.
"Best estimate"
methods are used in most, maybe all, FSARs for all beyond design basis events. SECY 93-087 and BTP 7-19 define CCF with concurrent
accidents
as a beyond design basis event. Now, you are using this RIS to change NRC policy. Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:40:21
AM Number: 5 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
11:44:21
AM This is not an alternate
approach.
It is your definition
of "sufficiently
low" Number: 6 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:43:50
1234
Page: 31Number: 1 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:01:52
PM "Best estimate"
methods facilitate
crediting
backups.
Without "best estimate"
methods backups cannot be credited
because they will never achieve the same performance
(e.g. response
time, design basis margin to critical
safety function
limits) as the original
system. Number: 2 Author: KenSc Subject:
Highlight
Date: 01/24/2018
11:59:40
AM Number: 3 Author: KenSc Subject:
Sticky Note Date: 01/24/2018
12:03:16
PM This is not an economical
means nor is it likely to show equivalent
design basis results.
This is why "best estimate"
methods are needed. Number: 4 Author: KenSc Subject:
Highlight
Date: 01/24/2018
12:02:23
This page contains
no comments
This page contains
no comments
This page contains
no comments
This page contains
no comments
This page contains
no comments