ML18025B924

From kanterella
Revision as of 00:57, 23 February 2018 by StriderTol (talk | contribs) (Created page by program invented by StriderTol)
Jump to navigation Jump to search
Summary of Comments on 2018-01-24 by Ken Scarola_Nuclear Automation Engineering
ML18025B924
Person / Time
Issue date: 01/24/2018
Revision: 0
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.pdfThis 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 9:03:14 AM ATWS is considered 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 confuse 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 CC 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 CC 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 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 PM 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 considere 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 AM 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 AM 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 AM 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 sufficientlylow 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 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 move 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 AM

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 AM 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 AM

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 AM

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 AM 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 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