Okay, I think it's time we start a new thread on this...

I looked again at the detailed descriptions. On some of them, it seems that they haven't tested at all yet, but closer look reveals that isn't necessarily the case.

Look at the RVLIS (Reactor Vessel Level Indication System). If you read the detailed description, you'd get the idea that they haven't even tested it yet. But if you go back in the report to the "Detailed Assessment" section, you'll see that they have tested it, and that, as the table indicates, it is not Y2K compliant, and it is being repaired.

I'd say that one item alone (as part of the plant safety system) is enough to prove my point.

Jon

-- Anonymous, February 18, 1999

Answers

I think many do not differentiate between "testing, as a part of the assessment process" and "testing, following remediation" to see if the remediation was successful.

-- Anonymous, February 18, 1999

Ultimate answer is for a concerned individual to call Seabrook's public relations office, or the NRC and ask them directly. Short of that:

Year 2000 Readiness Project Plan has 7 or 8 stages depending on how you read the final 2 steps. (ref. 2.2 Project Plan) 1. Awareness 2. Inventory 3. Assessment 4. Remediation 5. Testing 6. Validation 7. documentation and (8) signoff.

Executive Summary section # 4. states that Seabrook is in Remediation phase at the time of the audit. This could be evidence that testing is yet to come, but is not conclusive, since they could be concurrent for different devices.

Initial assessment includes inventory, categorization, classification, prioritization, and analysis of initial assessment. (ref 2.2 Initial Assessment.) Inventory completed 8/98.

Detailed assessment (section 2.2.3) includes analysis to encompass FAILURE IMPACT, Y2K STATUS & STRATEGY, and activities of planning and assessment signoff. (emphasis mine) Also note in 2.2.3 "Y2K CLASSIFICATION" (emphasis mine), based on "failure impact" is part of the Assessment stage (#3 above). Not yet to remediation stage. They are calling vendors to get initial responses (this was my 1st action also). Also note that the classifications match the columns of Table 2, which then are further detailed when the columns are given their own table (TAbles 4-7)

2.2.3 (page 6of17 using my fonts) also states "Once Y2K status of systems is determined, the STRATEGIES to achieve compliance is determined." Notice that the 4th column of Tables 4-7 record the STRATEGY. Still in the Assessment stage. Not to remediation yet. More clues that TAbles 4-7 were developed in Assessment stage.

CRITICAL Quote from 2.2.3 - "The plan notes that for vendor responses that ndicate an application or device is Y2K ready or compliant, a decision on whether to perform validation testing is required. This decision may be based on FAILURE IMPACT..."

SO...the vendor says a device is OK. Trust, or verify? To test or not to test, that is the question! Seabrook looks at the consequence of failure to determine WHETHER OR NOT TO TEST. So, a worst case failure is determined and noted in the IMPACT column of Tables 4-7. Not the result of testing, but to help decide whether to test. Quite reasonable. Contrary to the opinion often stated that the easy stuff is being tested first, they placed the priority on the Critical stuff.

Think about it, if the vendor tells you something is going to fail, why waste teh trouble verifying when you will replace anyway? If the vendor tells you all is ok, don't sweat the small stuff - test the critical stuff.

This brings about a disturbing point. If I am correct about the timing, they may have accepted the word of the vendor on several "compliant" safety related items. You can't absolutely deduce this (they may have a test schedule document that was not included), but the classification of safety related items as "compliant" before testing may be the "inconsistancy in the application of certain classifications" that the NRC noted (ref NRC letter at front of audit). If so, the NRC states that they were taking care of it. I take this to mean that safety related items were changed to a strategy of fix/test was probably adopted. Note that if "test" is the strategy that implies testing, critical items thought to be compliant would be labeled "fix" so as to target them for verification testing (NO FAILURE IMPLIED).

Also interesting is that 2.2.4 Y2K Testing and VAlidation and 2.2.5 Remediation appear to be in reverse order from the plan outline stated above. I believe this due to initial thoughts being to test after fixing known problems, and then realizing that you can't take the word of the vendor on safety related items - after the original plan outline was made. Effectively, the 7 (8) items above need to have some tested before remediation (and possibly after also - if they fail), and ones reported as problems by the vendor tested after remediation. The mid-stream change did not get reflected in the broader plan outline.

Now this makes perfect sense to the twisted mind that typed it. It probably makes no sense to normal people. Perhaps someone can summarize and comment on my thoughts in a more clear and concise manner. Factfinder?? (Oops, didn't mean to let my arrogance slip through (grin)).

-- Anonymous, February 18, 1999

OOps,

I forgot to mention something. To support my claim that vendor reported failures were classified prior to test, note in the Detailed Assessment section in reference to the failed safety related RVLIS system, "In ADDITION (emphasis mine) to the testing done by (vendor's name), the liscensee plans to do additional testing of the remediated RVLIS at the site." Note the FUTURE tense of the testing. Ask yourself, why test a system when the vendor has already provided you with test results showing its busted?

-- Anonymous, February 18, 1999

CL,

First, you have to test during the assessment phase. How do you know whether something is Y2K compliant or not without testing it?

Second, you quoted:

"In ADDITION (emphasis mine) to the testing done by (vendor's name), the liscensee plans to do additional testing of the remediated RVLIS at the site."

I think you put the emphasis on the wrong word :-) You really meant to put the emphasis on "remediated", right? After they fix the system (remediated), you have to test and make sure it actually works...

Jon

-- Anonymous, February 18, 1999

Jon,

If your tires is flat and is sitting on its rim, do you test the pressure with a tire gauge BEFORE you change it?

Read my second post (above). The 1st action is to write for a vendor letter stating status - if the vendor 1. Admits its broke. 2. Provides detailed test documentation proving its broke. Why spend precious resources testing to confirm what you know is already broke? Especially when you have oodles of stuff that is unknown.

My Assessment phase consisted of vendor inquiries and detailed technical review of schematics and IL's. (instruction leaflets). This was necessary to rule out any older devices that are not date-aware. We couldn't afford to waste time testing things, and ordering/requisitioning things that have no uP chips. (It isn't always evident from the outside without reviewing schematics).

Sorry, but I'd bet the farm I'm right on this one. Why don't you contact the NRC and ask them? You could then post here that I was right all along - I promise I'll stay humble. ; )

-- Anonymous, February 19, 1999

I'm going to reiterate my original point here, since it seems to be getting lost.

My point is as follows:

Quote from page 3 of the latest NERC report:

"Only a small percentage of components tested indicate problems with Y2k date manipulations. The types of impacts found thus far include such errors as incorrect dates in event logs or displays, but do not appear to affect the ability to keep generators and power delivery facilities in service and electricity supplied to customers."

My position is that this is an outright lie. The information in the Seabrook audit shows pretty conclusively that there is at least one safety-related system in the plant that has been tested or shown to be Y2K non-compliant, and must be fixed/replaced.

Anything that affects the safety of a nuclear plant has a direct effect on the generational capabilities of that plant. Therefore, NERC is either lying, or they don't know about the Seabrook audit. Either one of those cases is a bad position for them to be in.

Jon

-- Anonymous, February 19, 1999

Jon & CL, may I join this most gentlemanly fray?

Jon, You brought up some good points in earlier posts concerning digital control systems in nuclear power plants that I never did get back to you on (sorry), including the Seabrook audit. I'm not sure what your profession is, but of all the questions and challenges to those of us working inside the utility industry on Y2K, I believe you have some of the best I have seen posted here - as a matter of fact, I'm going to try to be real careful, because although I've real all of the NRC Y2K audits, I believe you and CL have studied them way more than I have. I did take the time to look more closely at Seabrook's.

Your challenge of the discrepancy between the NERC report and the findings identified in the NRC audits is commendable (good thing journalist don't dig as deep, from the way our industry is handling communications on Y2K the truth would never come out and it would look like one big scandal). I am going to take a shot at this though, with the goal of at least giving you a little more information to consider even if you don't agree with my view of the whole Nukes Y2K communications mess.

Lets get to the meat of the Seabrook audit and non-Y2K compliant safety systems. I gotta say that I agree with my personal hero CL's take on this audit, and he is absolutely right that once a vendor states that a component is non-y2k compliant, there's no point is wasting time testing, the time needs to be spent to get it fixed (even if it's a minor y2k bug that will not prevent the device from performing is primary functions).

One thing I did notice may provide some additional food for thought for both of you: The Seabrook NRC audit report lists the NI Boron Dilution Monitor as "Not Compliant" in Table 7 with a strategy of "Fix, Y2K Testing Required". Below the table, however, is the following note: "NI Boron Dilution Monitor - The Gammametrics Shutdown Monitor RCS-30 does not appear to be date aware. However, several clock functions are used and due to its importance to the plant will be evaluated further. " For this device at least, apparently not enough information was available (from the vendor, equipment manuals, etc.) to determine Y2K compliance during the assessment stage. It appears that the device was therefore conservatively assumed to be non-compliant pending testing (lumped in with testing of other devices during the remediation stage perhaps).

From this observation, you can see that not all components were tested during the assessment phase, and in this case at least, was "assumed" to be non-compliant. This may have been done for some other components as well. I am not sure about RVLIS - I actually did initial startup of this equipment at one plant, however the system was analog then and later upgraded to a digital system called ICCM. I am familiar with ICCM at the upgraded plant, but not with Seabrook's RVLIS - the description perplexes me, there are obvious differences from the system I am familiar with - for example the one I am familiar with had no control functions, reactor vessel water level and incore thermocouple monitoring only. I cannot determine for sure from the report whether there was an assumption that RVLIS is non-compliant until Westinghouse completed testing, or whether Westinghouse had already tested and determined that it was not compliant and then was to do further testing of the "fixed" system. (confusing, isn't it CL!) From what I know about RVLIS and ICCM, I doubt that a y2k bug would stop this system from performing its intended function (at least at the plants I am familiar with), but one never knows. I will try to follow up on the RVLIS y2k problem for you and find out exactly what it is.

A device that fails ANY date related function during a Y2K test, no matter how minor or insignificant, is classified as "non-compliant" (it may be "Y2K ready", but many people are accepting only "Y2K compliant" for embedded systems, especially in plant installations). Therefore one should not assume that a device classified as "non-y2k compliant" in the NRC audits will fail to perform its intended function, since the problem may be minor in nature, such as a date like "1/1/100" showing up on a screen or printout that should show "1/1/2000" or "1/1/00". As I have stated many times here before, almost all the problems I have found have been minor, with only a couple of significant problems (and never a failure of a device that controls something in the plant). My associates in the nuke industry inform me of similar findings. So it is very possible that a Y2K "non-compliance" of a safety system would not prevent the device from functioning and the NERC report could be accurate. Looking at the statement as you quoted from page 3 of the NERC:

"Only a small percentage of components tested indicate problems with Y2k date manipulations. The types of impacts found thus far include such errors as incorrect dates in event logs or displays, but do not appear to affect the ability to keep generators and power delivery facilities in service and electricity supplied to customers."

I have seen nothing that contradicts the "affect the ability" part of this statement, however if we do find a non-y2k compliant safety system that would have actually failed due to the bug, then the statement would be incorrect. I do not know of such a y2k failure in a safety system. It's not out of the realm of possibility, and I assure you, if I find out about such a system, I will let you know (as I am sure CL and Rick and others would). But the fact that a safety system is listed as 'non-compliant' doesn't give enough information on the nature of the Y2k problem to determine its impact. [If anything, I am not so sure about the "only a small percentage tested" part of the NERC statement. My limited experience has found a fairly high percentage of digital components with date functions are not fully y2k compliant, with similar findings on software. As stated, almost all minor problems. You CL, Rick, or anyone else? I think this would make a good topic of its own....]

By the way, it is incorrect to assume that everything must be tested by the utility to determine Y2K compliance - from reading the audits, you can see this is not always done. Vendor testing and certification is relied upon in many cases as CL pointed out. Regardless of what you read, there are a zillion issues involved in the vendor vs. utility testing decision. Let me state this flat out - some equipment is extremely complicated, and there is just no way that every utility can do a better job of verifying Y2K compliance than the vendor who makes it (of course CL and I can test anything, but I always feel just a tad better to see the vendors results the same as mine). I do think that all mission critical/safety related digital systems with date functions should be verified as a "second check" . For other systems, you do have to ascertain if you can rely on the vendor - the documentation and knowledge of the vendor are important here.

There's one other misconception about testing I have seen in many places - that you have to "test every chip". Testing is best done at the system level since the system (or equipment) as a whole must be compliant, and no, you do not have to test every device. Here's why - for common instruments such as digital chart recorders, you may have a hundred of these. Good quality vendors have very good configuration control - the vendor tracks design changes and firmware revision numbers (firmware is the embedded system equivalent of software, and often resides on EPROMs) . You can verify the firmware revision level on each recorder to determine if you have the version that the vendor (or utility) has tested and verified to be compliant. Confidence and knowledge of the vendor is important here. This is equivalent to testing software of a certain version. You may test one copy of Microsoft Excel 97 to verify Y2K compliance, but would you insist on testing every single copy on every single desktop PC? This adds no value, and the time is much better spent testing critical systems.

And finally, I believe that you said to me in an earlier post that some plants may be have more computerized equipment than others and may not reflect the plant I was working at (or something to that effect). You are absolutely correct about this. The plant I am currently at is an older vintage plant with less modern controls installed, although there are a lot of digital devices not directly installed in plant systems here. The plant I was at previously (and also did a limited amount of Y2k work at) had much more computerized equipment. Seabrook appears to have more modern computerized equipment than most nukes, which makes sense because it is a newer vintage plant with a commercial on-line date of 8/19/90. It's a 4 loop Westinghouse NSSS PWR with a GE turbine/generator.

I have found some additional NRC document links on the Internet concerning computer based digital systems used in nuclear plants that I am sure you will find interesting. I will post the links as a separate topic since I believe they will be of interest to many and they might not be found buried in this thread.

Geesh! I just reviewed all the typing I've done, never meant to get this wordy. Sorry all!

Regards, FactFinder

-- Anonymous, February 20, 1999

factfinder,

There is a risk inherent in taking the vendor's word that his problem is non-compliant. I seem to recall a breakout session at the last EPRI conf. where someone said that a vendor claimed to have a non-compliant system and an upgrade w/fix for a fee. Testing showed that the product was really ok - the vendor was looking to turn a buck. Moral of the story, don't just accept vendor letters, (especially when it is apparent it came from a sales or lawyer type person) demand to see the vendor's test results.

-- Anonymous, February 20, 1999