Carl, Tom Tomlinson (RETAQS) also gave me the same story on the Fuel Failure issue and its impact on Reactivity Management. In this case, I do feel you could potentially bin this in Level 2 space because of how it failed. However, that may not be indicative of the health of your RM Program.
We agree with your issue about fuel issues not all belonging under RM issues. BWROG RCRC is developing another PI looking at Fuel-related issues that would not fall under reactivity management for exactly that reason. We did get some input from PWR's on it and are also including INPO up-front. It will be some time before we have a product ready for use on that.
For you final issue, on technical product, in my opinion, it is Level 4 since it doesn't impact operation. I have attached a discussion on similar topics. They are examples that had happened recently at BWR's and we discussed them at the January RCRC meeting. Many of them are BWR specific examples, but some would apply to both and certainly the concepts could be applied. From the description you've given below, it appears that it looks much like events described on Slides 9, 11, 15 and 16. It would be consistent with Level 4 in all of those examples.
Ed McVey
________________________________
From: pwrrm@retaqs.com [mailto:pwrrm@retaqs.com] On Behalf Of Fago, Carl D Sent: Thursday, April 08, 2010 5:44 AM To: PWR Reactivity Management Subject: Re: [Pwrrm] PWROG RM Coding Questions
With regard to the delta between the BWROG and PWROG for fuel failures, as I recall from the meeting in Pittsburgh, the basis was that a fuel failure for PWRs is potentially significantly less RM impact than a fuel failure for BWRs. Since PWRs don't suppress failures, only certain cases do failures impact RM in any way. Thus, those that do should be treated the same as SL3 events but those that don't are either not RM at all (say low power grid-to-rod fretting failures) or a lower event level (L4 for fuel handling issue that results in damage).
The other issue that needs to be discussed in Philly is that RM needs to be just that, RM. Not all fuel issues are RM-related. There are really big deals that are not RM big deals. (ONS fuel damage event for instance). If INPO wants to encompass all fuel issues in any way, shape or form, within RM then INPO 06-06 and SOER 07-1 need to change to reflect that. Currently they don't encompass what I hear second hand that INPO wants. My management has also pushed back on some of the PWROG criteria based on the issue not being RM per the definition and I've asked them to provide that feedback to INPO.
On a different note, another example just to make sure we're implementing consistently...
* An error in the core cycle design calculations for a current operating cycle that either does not result in any change to the COLR or the design deliverable document used at the plant for managing the operating core. (Say, a conservative error in the analysis for a non-limiting event ... thus the AO, rod insertion or tilt limits are not changed.)
- SL4 as a technical error in an RM product after implementation but no impact to operation? (it's been implemented, though, so the information has been "used")
- SL3 does not seem to apply since the error does not impact operation.
- Or is it even lower than SL4 since the site documents (COLR, etc.) did not have an error ... only the basis calculation did?
Thanks!
Carl
Carl D. Fago
Reactor Engineering Supervisor
Oconee Nuclear Station
Duke Energy Carolinas
Phone: (864) 873-3047
Fax: (864) 873-3374
Email: Carl.fago@duke-energy.com
From: pwrrm@retaqs.com [mailto:pwrrm@retaqs.com] On Behalf Of edward.mcvey@exeloncorp.com Sent: Tuesday, April 06, 2010 2:04 PM To: pwrrm@retaqs.com Subject: Re: [Pwrrm] PWROG RM Coding Questions
See my responses below. Some of these are good topics for our meeting in July in Philly.
Ed McVey
________________________________
From: pwrrm@retaqs.com [mailto:pwrrm@retaqs.com] On Behalf Of Fago, Carl D Sent: Tuesday, April 06, 2010 11:59 AM To: pwrrm@retaqs.com Subject: [Pwrrm] PWROG RM Coding Questions
During our transition to the use of the PWROG RM event coding, several questions arose and we'd like to get some feedback on how others are handling similar issues. Specifically...
1. For multi-unit sites, if there is an issue generic to all units (e.g., vendor core design analysis method error), are you applying the "hit" to all applicable units equally? Most definitely.
2. For those sites with dry storage (or event multi-unit sites with dry storage), how are you addressing issues with cask transport to dry storage (e.g., while transporting a cask the trailer/transporter breaks)? Is this an issue of less than adequate fuel handling equipment performance while handling fuel or control component (no fuel/component damage), L5? If so, for multi-unit sites, which unit would get the RM hit based on dry storage? We don't really address that very well. That may be an item for clarification in the next revision. I would take your pick on the unit. Probably, if only one unit's fuel is involved, then use that unit (like you do in 3 below). Otherwise, either would suffice.
3. ONS has a shared fuel pool between Unit 1 and 2. For fuel handling practices / equipment issues, we are proposing to apply any RM hit against the unit to which the specific fuel assembly or control component last operated. As far as we can tell, there is no "hit" if the fuel bridge or other equipment fails when fuel is not being handled, therefore, there will always be a unit that can be associated with the event. That sounds appropriate to me.
4. ONS Fuel Damage Event (SEN-280) has been classified as L4 based on fuel handling that results in damage to fuel assembly or control component. While the RM level isn't indicative of the organizational significance of the event, this is the classification we came up with. Any comment or insights into how others might classify this event? (While we weren't "handling fuel" at the time, we conservatively said it met the intent.) Note that there was no specific RM impact in the event (again, this was a big event for ONS but we're specifically focusing on RM for this question.) This is definitely a weakness in the PWR RM PI. The PWR PI puts a fuel failure at Level 4 versus the BWR PI puts it at Level 3. Also, the BWR PI would also have gotten you to Level 3 in that an emergency core redesign due to fuel damage, would also have gotten you to Level 3. You could also call it a Level 2 since technically you could argue that it failed due to "operational" issues. I can tell you that my discussions with INPO on classification of an event like this as a Level 4 would cause them serious heartache. That was one of the major issues that they had with the PI, was how could fuel handling damage be considered so low. That's why it got elevated in the BWR PI. Not sure why the PWR team arrived where they did on that one. I think the only justification you have is that it does not necessarily reflect the health of your RM program. Although, someone else might argue that could be because you haven't gotten the right sensitivity in the entire organization to ensure all personnel realize their potential impacts to Reactivity Management and Fuel Integrity. If you look at the standard philosophy of Reactivity Management (see below for Exelon's which was taken from other industry documents), you are suppose to operate fuel such fuel failure does not occur. In your event, a maintenance activity caused the fuel to fail. That has to be more than a Level 4 event. If you can't bin it under a standard example, then use management discretion to elevate. The examples that we have couldn't think of all the possibilities of things happening, but I'm pretty sure that had we thought your event was possible, it would have been binned under something higher than Level 4.
"
Thanks in advance for all the feedback!
Carl
Carl D. Fago
Reactor Engineering Supervisor
Oconee Nuclear Station
Duke Energy Carolinas
Phone: (864) 873-3047
Fax: (864) 873-3374
Email: Carl.fago@duke-energy.com
************************************************** This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You. **************************************************
----------------------------------------- ************************************************** This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You. **************************************************
