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
1 2 3 4
Page: 3 Number: 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
1 2
Page: 4 Number: 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
1 2 3 4
Page: 5 Number: 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
1 2
Page: 6 Number: 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 create a 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
1 2 3 4
Page: 9 Number: 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
1 2
Page: 10 Number: 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.
1 2 3 4 5 6
Page: 11 Number: 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 AM
1 2 3 4 5 6
Page: 12 Number: 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 PM
1 2 3 4 5 6 7 8 9 10
Page: 13 Number: 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 c omparable
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 AM
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Page: 14 Number: 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 AM
1 2
Page: 15 Number: 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 AM
1 2 3 4 5 6 7 8
Page: 16 Number: 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 AM
This page contains no comments
1 2 3
Page: 18 Number: 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
1 2
Page: 21 Number: 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 AM
This page contains no comments
This page contains no comments
This page contains no comments
1 2 3 4
Page: 25 Number: 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 AM
1 2
Page: 26 Number: 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 AM
This page contains no comments
1 2
Page: 28 Number: 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 AM
This page contains no comments
1 2 3 4 5 6
Page: 30 Number: 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 without Staff 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 AM
1 2 3 4
Page: 31 Number: 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 PM
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