ML20050B172
| ML20050B172 | |
| Person / Time | |
|---|---|
| Site: | Waterford  |
| Issue date: | 03/31/1982 |
| From: | ABB COMBUSTION ENGINEERING NUCLEAR FUEL (FORMERLY |
| To: | |
| Shared Package | |
| ML19268D129 | List: |
| References | |
| CEN-195(C)-NP, CEN-195(C)-NP-R, CEN-195(C)-NP-R00, NUDOCS 8204050068 | |
| Download: ML20050B172 (19) | |
Text
. -. _. -. _ _.
CEN 195(C)-NP
++
~
CPC/CEAC PROTECTION ALGORITHM TEST PLAN WATERFORD STEAM ELECTRIC STATION UNIT NO. 3 MARCH,1982 o
g gPOWER DO K O O O 82 ccueusr1CN ENGINEERNG N A
pon
%e l
LEGAL NOTICE THIS REPORT WAS PREPARED AS AN ACCOUNT OF WORK SPONSORED BY COMBUSTION ENGINEERING, INC. NEITHER COM8USTION ENGINEERING NOR ANY PERSON ACTING ON ITS BEHALF:
A.
MAKES ANY WARRANTY OR REPRESENTATION, EXPRESS OR IMPLIED INCLUDING THE WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE OR MERCHANTABILITY, WITH RESPECT TO THE ACCURACY, COMPLETENESS, OR USEFULNESS OF THE INFORMATION CONTAINED IN THIS REPORT, OR THAT THE USE OF ANY INFORMATION, APPARATUS, METHOD, OR PROCESS OlSCLOSED IN THIS REPORT MAY NOT INFRINGE PRIVATELY OWNED RIGHTS:OR B. ASSUMES ANY LIABILITIES WITH RESPECT TO THE USE OF, OR FOR DAMAGES RESULTING FROM THE USE OF, ANY INFORMATION, APPARATUS, METHOD OR PROCESS DISCLOSED IN THIS REPORT.
i i
i l
l l
- -- - J
l ARSTRACT This document presents the approach that will be taken for testing and certifying the CPC/CEAC System Software for the Waterford Steam Electric Station - Unit 3 plant. Sections
- s. this document describe the purpose and scope for testing, types of testing to be performed, and documentation to 5
support the algorithm changes and test results. The testing will be performed in accordance with the procedures of CEff-39(A)-P, Revision 2 and Supplement 1-P, Revision 00. Specific tests which are being performed because of the changes being made to the algorithms are specifically discussed.
e Revision 00 Page 3 of 19
TABLE OF CONTENTS Section Title Page No.
1.0 SPECIFICATION FOR TESTING PROTECTION ALGORITHM S
1.1 PURPOSE 5
1.2 SCOPE 5
1.3 MODIFICATION REOUIREM.ENTS 6
2.0 IMPLEMENTATION AND TESTING 7
2.1 SCOPE OF IMPLEMENTATION AND TESTING 7
2.2 IMPLEMENTATION AND DISK GENERATION 7
2.3 PHASE I TESTING 7
2.4 PHASE II TESTING 8
2.4.1 Input Sweep Test 8
2.4.2 Dynamic Sof tware Verification Test (DSVT) 9 2.4.3 Live Input Sinale Parameter (LISP) Test 10 2.5 PHASE I TEST CASE SELECTION AND ACCEPTANCE CRITERIA 11 2.6 PHASE II TEST CASE SELECTION 11 2.7 GENERATION OF PHASE II ACCEPTANCE CRITERIA 16 3.0 GENERATION OF MASTER DISKS AND SOFTWARE DESIGN DOCUMENTATION 18
4.0 REFERENCES
19 LIST OF TABLES Table No.
Title Page No.
2.6-1 Dynamic Sof tware Verification Test Cases 14' Revision 00 Page 4 of 19
l l
1.0 SPECIFICATION FOR TESTINr. PROTECTION ALGORITP11 1.1 PURPOSE The purpose of this document is to outline the approach that will be taken for testing and certifying the CPC/CEAC System (CPCS) software for the Waterford Steam Electric Station - Unit 3 (Waterford-3) Plant of Louisiana Power and Light Company. The testing outlined here is described in more detail in Reference 4.1.
The implementation of the algorithm changes, the required testing, and the documentation will be performed and/or generated in accordance with the procedures of Reference 4.1.
1.2 SCOPE The scope of the testing will include generation of a plant-specific data base and document, generation of appropriate test cases and acceptance criteria, and test reports.
Testing of the CPCS software for Waterford-3 will be considered complete with the formal issuance of the following documents:
1.
Waterford-3 CPC/CEAC Data Base Docum(nt 2.
The Phase I Test Report 3.
The Phase II Test Report All documents will be generated and reviewed in accordance with the procedures given in Reference 4.2.
In addition, all tests will be
~
performed according to the procedures described in Reference 4.1, and the results documented in accordance with the procedures given in Reference 4.2.
Together these steps will reflect the complete OA'd
^
status of the CPCS sof tware specification and implementation for
/-
Waterford-3.
=
Revision 00 Page 5 of 19 I
1.3 MODIFICATION REQUIREMENTS The modifications being made to.the Waterford-3 CPCS software are to upgrade the CPCS capabilities to be compatible with the Reactor Power Cutback System (RPCS). The RPCS is designed to rapidly reduce the reactor power by dropping pre-selected CEA groups in response to either a large load rejection or loss of one feedwater pump, without
[.
tripping the plant. These modifications consist of changes and additions to algorithms in the CEAC to detect the actuation of an RPC event, a flag in the CEAC penalty factor word to transmit to the CPCs the information that an RPC is in progress, and a more accurate down-power transient calculation in the event of an RPC.
In addition, the positive range limit of the addressable constants for the DNBR and LPD penalty factor multipliers is being shifted toward zero to cover more completely the range of applicability. These modifications are described in more detail in Reference 4.3.
The modification process was initiate.1 when details of the modification were established by the responsible C-E engineering, group. The modifications will be incorporated into a revision to the CPC and CEAC Functional Design Specifications. Plant-specific constants will be generated for Waterford-3, and a Data Base Document recording these constants will be generated. Since these modifications impact the CPC/CEAC FORTRAN code, the CPC/CEAC FORTRAN code certification document will be revised. All revisions to the Functional Design Specifications and to the FORTRAN code will be done in accordance with the requirements of Reference 4.2.
Additional requirements for software functional design changes are described in more detail in Reference 4.1.
n..+
.=.
n..
Revision 00 Page 6 of 19
2.0 IMPLEMENTATION AND TESTING 2.1 SCOPE OF IMPLEMENTATION AND TESTING This section covers the implementation of the algorithm changes and performance of Phase I and Phase II testing including test case selection and generation of acceptance criteria.
~
2.2 IMPLEMENTATION AND DISK GENERATION All algorithm changes will be documented on Software Change Requests (SCR) and will be transmitted to the software implementation group.
The procedures for filling out and processing an SCR are covered in more detail in Reference 4.1.
The most recent revisions of CPCS Software Specifications will be revised to reflect all software modifications indicated by the SCR's, and the resulting documents will be reviewed in accordance with Reference 4.2.
The algorithm change will then be implemented, and all CPC/CEAC source files affected by the change will be updated. The updated CPC/CEAC source files will then be assembled to create object modules on the Waterford-3 project disk. The object modules will then be fully debugged. Once debugged, the project disk will be used to generate two reference disks (Channels A/B and C/D). Phase I and Phase II testing will be performed on the Channel A/B reference disk.
2.3 PHASE I TESTING Phase I testing will be performed to verify the correct imp ementation of modifications to the CPCS sof tware and the i.
generation of a new set of program constants. Phase I testing is performed on relatively small, single-entry / single-exit segments of code called modules as well as for integrated modules which cnnstitute individual programs. Test cases will be generated for each and every module and for program-wide testing.
Revision 00 Page 7 of 19
l l
Except for Phase I testing of the CPCS Executive software, all test cases will be transmitted to the functional design group which will execute the test cases with the CPC/CEAC FORTRAN code. The results will then be returned to the sof tware implementation group which will execute the test cases on the CPCS software and compare the results with those from the FORTRAN code. The CPCS executive software will be tested following any change made to it by comparing actual and expected hand-calculated results for selected test cases. These
[-
comparisons will be analyzed to ensure correct implementation of all modifications affecting the CPCS executive and application program software. The scope and results of this testing will be documented in the Waterford-3, Phase I Test Report.
2.4 PHASE II TESTING Phase II testing consists of the following tests:
(1)
Input Sweep Test, (2) Dynamic Sof tware Verification Test, and (3) Live Input Single Parameter Test.
These tests are performed on a single channel CPC/CEAC system with integrated sof tware that has undergone successful Phase I testing.
The objectives of Phase II testing are described in Reference 4.1.
The Phasa !! testing uses the CPC/CEAC FORTRAN code as a basis for comparison and for generat;ng acceptance criteria.
The results of the Phase II testing will be documented in the Phase II Test Report.
2.4.1 Input Sweep Test The Input Sweep Test is a real-time exercise of the CPCS application program sof tware and executive sof tware with steady-state CPC input values read f rom a storage device.
The objectives of the Input Sweep
_ Test are described in Reference 4.1 and are summarized below:
Revision 00 Page 8 of 19
(1)
To determine the processing uncertainties resulting from differences in machine precision between the CPC/CEAC system hardware and the CDC 7600.(on which the FORTRAN code is executed). The processing uncertainties will be factored into acceptance criteria for the other two Phase II tests and into CPC Data Base constants affected by these uncertainties.
(2)
To verify the ability of the CPCS software algorithms to initialize to a steady state after an Auto-Restart for each test Case.
(3)
To complement Phase I individual module and program-wide testing by identifying any abnormalities which were not uncovered previ ously.
The Input Sweep Test will be performed in two segments. The CPC software and the CEAC software segments will be independently tested.
Each segment will have its own test cases and acceptance criteria for pr essing uncertainties. Each segment will be first executed on the CPCJ sof'. fare by the sof tware implementation group. The test cases will be allowed to initialize by convergence of critical calculated parameters, after which calculated parameter values will be transferred to the functional design group. The functional design group will execute the same test cases on the CPC/CEAC FORTRAN code and will tnen perform a comparison between the two sets of calculated parameter values. Part of this comparison will be a statistical evaluation which will generate the processing uncertainties. The results of this comparison will be evaluated to ensure the test objectives have been met.
2.4.2 Dynamic Sof tware Verification Test (DSVT)
The Dynamic Sof tware Verification Test is a real-time exercise of the CPC application software and executive software with transient CPC input values read from a storage device. The objectives of the DSVT are described in Reference 4.1 and are. summarized below:
Revision 00 Page.9 of 19
es 7:0+
(1)
To verify that the dynamic response of the integrated CPC software is consistent with that predicted by design analyses, and (2)
To supplement other Phase I and Phase II tests in assuring correct implementation of the software modifications.
The DSVT cases will be executed on the 'CPC/CEAC FORTRAN code to generate the acceptance criteria. The DSVT cases will then be executed on the CPCS software.
Input values for each test case will be read from a storage device. After initialization for each test case, DSVT will use time-variant test. case input values to more thoroughly exercise " dynamic" portions of the CPCS software. The results of this test will be compared with the acceptance criteria and evaluated to ensure the test objectives have been met.
2.4.3 Live Input Single Parameter (LISP) Test The LISP test is a real-time exercise of the CPCS application and executive software, with transient CPCS input values generated from an external signal generator and read through the CPCS input hardware.
The objectives for the LISP test are described in Reference 4.1 and are summarized below:
1 (1)
To verify the dynamic response of the integrated CPCS software and hardware.
(2)
To supplement other Phase I and Phase II tests in assuring correct implementation of the software modifications.
(3)
To evaluate the integrated hardware /sof tware system during operational modes.
The LISP test cases will first be executed on the CPC/CEAC FORTRAN
, code to generate the acceptance criteria. The LISP test cases will Revision 00 Page 10 of 19 i
then be executed using the CPCS software. Dynamic test case inputs will be generated by an external signal generator to produce " live" analog and digital signals that are input to the CPCS input processing hardware. Each LISP test case will vary only one input parameter, holding the other inputs at constant values. The LISP test also exercises all dynamic portions of the CPCS software algorithms. The
.[
results of this test will be compared with the acceptance criteria and evaluated to ensure the test objectives have been met.
As part of the LISP test, major aspects of the operator's module operation will be tested. The CPC and CEAC Point ID tables will be checked to ensure that the Point ids displayed on the operator's module are the same as those listed in the Point ID tables. The lower and upper range limits for all addressable constants will be tested and verified as having been correctly implemented. Finally, all aspects of automated reentry of addressable constants will be tested and verified to be correctly implemented.
2.5 PHASE I TEST CASE SELECTION AND ACCEPTANCE CRITERIA For Phase I testing, test cases will be generated for all modules.
These test cases will include cases to exercise all modifications, including those related to RPC. The selection of test cases will ensure that each functional branch and each instruction in all modules will be exercised. Progran wide test cases will then be run to assure correct transfer of information between modules of the same program and compatibility of the RPC modifications.
The acceptance criteria will be allowable difference s
between the expected results and the actual res61ts.
di f ferences greater than[~
~
However, all shall be investigated, and their causes verified as not being due to software errors or corrected.
2.6 PHASE II TEST CASE SELECTION THE CPC Input Sweep Test cases ere selected to cover the region of CPC
~
operation. Approximately test cases will be generated. Test Revision 00 Page 11 of 19
case parameters will be varied over the range of CpC inputs with the following additional variations applied over certain test case ranges:
J The CEAC Input Sweep Test cases are selected to cover various CEA
" ~~
l configurations. Approximately test cases will be generated. The majority of these test cases will encompass the CEA configurations expected during normal operation. The test cases in this first group Test cases in the second group will cover the following conditions:
l J.a
~*:--
s a
.e Revision 00 Page 12 of 19
~~
~
Because of the static nature of the CEAC Input Sweep Test, no RPC-related test cases are included in this test.
The DSVT cases are selected to adequately exercise dynamic portions of the CPCS application software. The test cases that will be generated for this test are listed in Table 2.6-1.
This list includes test cases to evaluate the CPCS software response to a RPC. These test cases will verify that the CPCs respond correctly during a RPC event and that the CPCs will not generate a reactor trip for RPC events which are progressing normally and do not require a trip.
The LISP test cases are selected to demonstrate that the integrated CPCS hardware / software system functions as designed in response to externally-generated transient input signals'in a real time envi ronment. The test cases will consist of variations of single variables encompassing cases 17 through 21 of Table 2.6-1.
Since the LISP test evaluates trip time based on transient input signals, no RPC-related test cases are included in this test.
's.
Revision 00 Page 13 of 19
1 1
l i
TABLE 2.6-1 Pynamic Sof tware Verification Test Cases a
s Revision 00 Page 14 of 19
l TABLE 2.6-1 (Cont.)
SINGLE VARIABLE 1
i i
e
'a.
j i
4 Revision 00 Page 15 of 19
2.7 GENERATION OF PHASE II ACCEPTANCE CRITERIA The acceptance criteria for the CPC Input Sweep test are that:
(1) The processing uncertainties fall within the guidelines described in Reference 4.1, l
(2)
Initialization capability is demonstrated, and (3) No software errors are detected.
This test will be performed on the CPC software and the CDC 7600. The CDC 7600 will then compare the results from both executions, case by case, evaluate the magnitude of the difference between calculated DNBRs and LPDs, and generate processing uncertainties.
The acceptance criteria for the CEAC Input Sweep test are similar to those for the CPC Input Sweep Test. The test will be performed en the CEAC software and the CDC 7600. Comparison and evaluation of results will be performed in a manner similar to that for the CPC Input Sweep Test.
The DSVT acceptance criteria are based on The acceptance criteria for will be determined by applying the processing uncertainties determined during CPC Input Sweep Testing to calculated with the CPC/CEAC FORTRAN c' ode. To determine acceptance criteria for jeThe dynamic cases will then be run on the CPC/CEAC FORTRAN code to produce acceptance criteria.
The acceptance criteria for the LISP test will consist of Revision 00 Page 16 of 19
h l
i will be factored into the acceptance l
' criteria. Each case will be' executed several times on the CPC/CEAC 2
FORTRAN code to generate the acceptance criteria.
i I
I L
I 1
I, I,
1 i
i i
i i
J Revision 00 Page 17 of 19 i
E
3.0 GENERATION OF MASTER DISK AND SOFTWARE DESIGN DOCUMENTATION The generation of a reference disk for Phase I and Phase II testing was described in Section 2.2.
Once the testing is satisfactorily completed, the two reference disks described in Section 2.2 will become the new reference disks for the software system. Additionally, several steps will be talJn in generating various software disks which will produce individual channel System Load Disks and System Test
~
Disks. The four System Load Disks and four System Test Disks will be transmitted to the plant.
During the software development and testing, documentation will be generated to document the changes, verify quality assurance of the CPCS software, and document the results of the testing. These documents will include:
(1) CPC/CEAC Data Base Document (2) Phase I and Phase II Test Reports (3)
CPC/CEAC Software Modifications Document (Reference 4.3) l t
'O l
1 Revision 00 Page 18 of 19 l
4.0 REFERENCES
2 4.1 CPC Protection Algorithm Sof tware Change Procedure, CEN-39(A)-P, Revision 02, and Supplement 1-P, Revision 00, j
4.2 Ouality Assurance of Design Manual for C-E Nuclear Power Systems, a
e 4.3 CPC/CEAC Sof tware Modifications for Waterford Unit 3, CEN-197(C)-P.
A i
f I
'h Revision 00 Page 19 of 19
I I
COMBUSTION ENGINEERING, INC.
i l
l e
l