ML20140E524: Difference between revisions
StriderTol (talk | contribs) (StriderTol Bot insert) |
StriderTol (talk | contribs) (StriderTol Bot change) |
||
| Line 18: | Line 18: | ||
=Text= | =Text= | ||
{{#Wiki_filter: | {{#Wiki_filter:. | ||
l t t | l t | ||
From: | t From: | ||
Date: | Curtis Rapp, /ttg To: | ||
ATP2.ATB e4 doc 4wajgp Date: | |||
10/29/9611:04am | |||
==Subject:== | ==Subject:== | ||
Additinal VIO for St. Lucie l | Additinal VIO for St. Lucie l | ||
Here is the Wordperfect version as you requested. | |||
l I | l I | ||
I i | I i | ||
l l | l l | ||
l J | l J | ||
9704290015 970423 | |||
/' | |||
PDR FOIA BINDER 96-405 PDR L | |||
s i | s i | ||
i The licensee also identified that BEACON was placed into service on Unit I without any benchmarking against IMPAX, the on-line core performance monitoring code BEACON was replacing. Instead, BEACON was installed on Unit 2 and benchmarked against CECORE, | i The licensee also identified that BEACON was placed into service on Unit I without any benchmarking against IMPAX, the on-line core performance monitoring code BEACON was replacing. Instead, BEACON was installed on Unit 2 and benchmarked against CECORE, j | ||
which did not require any modifications to accommodate the core midplane offset. Engineering | |||
which did not require any modifications to accommodate the core midplane offset. Engineering | ~ | ||
Quality Instruction (QI) 3.7, Computer Software Control, revision 1, Section 5.4. requires that SQAl software shall be validated and verified (V&V'ed) in accordance with Section 5.6 | Quality Instruction (QI) 3.7, Computer Software Control, revision 1, Section 5.4. requires that SQAl software shall be validated and verified (V&V'ed) in accordance with Section 5.6. | ||
Section 5.6 states that new software shall be V&V'ed prior to use. V&V includes the use of test | Section 5.6 states that new software shall be V&V'ed prior to use. V&V includes the use of test cases to ensure the new software produces correct results. Item 4 of Section 5.6 states that technical adequacy shall be determined by comparing the test case to results from altemative | ||
cases to ensure the new software produces correct results. Item 4 of Section 5.6 states that technical adequacy shall be determined by comparing the test case to results from altemative | ' methods such as functionally equivalent and previcusly validated software. In the case of l | ||
BEACON, IMPAX would have been functionally equivalent software. Benchmarking BEACON against IMPAX may have identifed the design error concerning core midplane offset because the two codes would not have yielded the same results. Contrary to this requirement, BEACON was placed into service on Unit I without benchmarking against IMPAX. This is a i | |||
BEACON against IMPAX may have identifed the design error concerning core midplane offset | Severity Level VI violation. | ||
because the two codes would not have yielded the same results. Contrary to this requirement, BEACON was placed into service on Unit I without benchmarking against IMPAX. This is a | l NOTE TO PANEL: This could be considered another example ofinadequte PMT as identified in EA 95-182. V&V is the post-mod acceptance test for software. | ||
EA 95-182. V&V is the post-mod acceptance test for software. | |||
i l | i l | ||
i i | i i | ||
Latest revision as of 16:41, 11 December 2024
| ML20140E524 | |
| Person / Time | |
|---|---|
| Site: | Saint Lucie  |
| Issue date: | 10/29/1996 |
| From: | Curtis Rapp NRC OFFICE OF INSPECTION & ENFORCEMENT (IE REGION II) |
| To: | Boland A NRC OFFICE OF INSPECTION & ENFORCEMENT (IE REGION II) |
| Shared Package | |
| ML20140E502 | List: |
| References | |
| FOIA-96-485 NUDOCS 9704290015 | |
| Download: ML20140E524 (2) | |
Text
.
l t
t From:
Curtis Rapp, /ttg To:
ATP2.ATB e4 doc 4wajgp Date:
10/29/9611:04am
Subject:
Additinal VIO for St. Lucie l
Here is the Wordperfect version as you requested.
l I
I i
l l
l J
9704290015 970423
/'
s i
i The licensee also identified that BEACON was placed into service on Unit I without any benchmarking against IMPAX, the on-line core performance monitoring code BEACON was replacing. Instead, BEACON was installed on Unit 2 and benchmarked against CECORE, j
which did not require any modifications to accommodate the core midplane offset. Engineering
~
Quality Instruction (QI) 3.7, Computer Software Control, revision 1, Section 5.4. requires that SQAl software shall be validated and verified (V&V'ed) in accordance with Section 5.6.
Section 5.6 states that new software shall be V&V'ed prior to use. V&V includes the use of test cases to ensure the new software produces correct results. Item 4 of Section 5.6 states that technical adequacy shall be determined by comparing the test case to results from altemative
' methods such as functionally equivalent and previcusly validated software. In the case of l
BEACON, IMPAX would have been functionally equivalent software. Benchmarking BEACON against IMPAX may have identifed the design error concerning core midplane offset because the two codes would not have yielded the same results. Contrary to this requirement, BEACON was placed into service on Unit I without benchmarking against IMPAX. This is a i
Severity Level VI violation.
l NOTE TO PANEL: This could be considered another example ofinadequte PMT as identified in EA 95-182. V&V is the post-mod acceptance test for software.
i l
i i
I 1
4