ML20050A937

Nonproprietary Cpc/Ceac Protection Algorithm Test Plan.

ML20050A937
Person / Time
Site:	05000470
Issue date:	03/31/1982
From:	ABB COMBUSTION ENGINEERING NUCLEAR FUEL (FORMERLY
To:
Shared Package
ML19268D122	List: ML20050A934 ML20050A935 ML20050A936 ML20050A937
References
PROC-820331, NUDOCS 8204020418
Download: ML20050A937 (19)

Text

- _ _ _ _ _ _

l l

l SYSTEM 80 00CKET STft-50 '70F E?! CLOSURE 2 ?!P TO LD-82-039 CPC/CEAC PROTECTIO?! ALGORITH?1 TEST PLA?!

MARCH, 1982 i

Comou stien Engi neering, Inc.

l i;uclear Pcwer Systens I i

Dower System Grcup Nindsor, Connecti cut 8204020418 820330 PDR AC"CK 05000470 A PDR @ POWER L'iEi1 SYSTEMS j msm a o # .r .; -

LEGAL NOTICE i

This report was prepared as an account of work sponsored by ,

Cenbustion Engineering, Inc. Neither Ccabustion Engineering l 4 ..or any person acting on its behalf:

A. Makes any warranty or representation, express or i implied including the warranties of fitness for a  !

particular purpose or merchantability, with respect to ,

the accuracy, completeness, or usefulness of the i

information contained in this report, or that the use i of any information, apparatus, method, or process ,

disclosed 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.

j e

e 1

I

)

]

4 I

1 l

• 1 i

t ,

i i

-- - - - . ._- . . . _-- _ _ _ - _ - - _a

- - .- =___ _

1 i

ABSTRACT l

i i

I This document presents the approach that will be taken for testing and

)

certifying the CPC/CEAC System Software for the System 80 plants. Sections in this document describe the purpose and scope for testing, types of l

testing to be performed, and documentation to support the algorithm changes l and test results. The testing will be performed in accordance with the j procedures of CEN-39( A)-P, Revision 2 and Supplement 1-P, Revision 00. i Specific tests which are being performed because of the changes being made {

j to the algorithms are specifically discussed. 1 I

i

)

4 1

1 i

i 1

i i

l' a

L l

Revision 00 Page 3 of 19 l 1

l

TABLE OF CONTENTS Section Title Pace No.

1.0 SPECIFICATION FOR TESTING PROTECTION ALGORITHM 5 1.1 PURPOSE 5 1.2 SCOPE 5 1.3 MODIFICATION REOUIREMENTS 5 2.0 IMPLEMENTATION AND TESTING 7 2.1 SCOPE OF IMPLEMENTATION AND TESTING '

2.2 IMPLEMENTATICN AND DISK GENERATION 1 2.3 PHASE I TESTING 7 2.4 PHASE II TESTING 3 2.4.1 Inout Sweeo Test 8 2.4.2 Dynamic Sof tware Verification Test ( DSV T' 9 2.4.3 Live Inout Single Parameter (LISP) Test 10 2.5 PHASE I TEST CASE SELECT!ON AND ACCEPTANCE CRITERIA 11 2.6 PHASE II TEST CASE SELECTION 11 2.7 GEtlERATION OF PHASE II ACCEPTANCE CRITERI A ,

16 3.0 GENERATION OF MASTER DISKS AND SOFTWARE DESIGN DOCUMENTATION 18

4.0 REFERENCES

19 LIST OF TABLES

/',

Table No. Ti tl e Page Fa. l 2.6-1 _ Dynamic Sof tware Verification Test Cases la l Revision 00 Page' 4 of 19 1

\

, 1.0 , SPECIFICATION FOR TESTING PPOTECTION ALGORIT'r:M

~

1.1 PhRdSE Th'e purpose of this document is to outline the approach that will be taken for testing and certifying the CPC/CEAC System (CPCS) sof tware for the System 80 plants. 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 d.1.

1.2 SCOPE The scope of the testing will include generar. ion of a plant-specific data base and document, generation of appropriate test cases and acceptance criteria, and test reports. Testing of the CPCS sof tware for each Systen 80 plant will be considered complete with the formal issuance of the follcwing plant-specific docurents:

1. CPC/CEAC Data Base Document

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 d.2. In addition, all tests will be performed according to the procedures described in Reference 4.1, and c

the results documsnted in accordance with the procedures given in i

Reference 4.2.' / Together these . steps will reflect the complete QA'd status of the CPCS sof tware specification and implementation for Systema 20.

/;

1.3 ( PODIFICATbhREQUIREMENTS The modifications being made to the System 80 C?CS sof tware are to l upgrade the CPCS capabilities to be conpatible with tne Reactor Pcwer i Cutback System (RPCS). The/ RPCS is designed to rapidly reduce the k[

reactor power by dropping pre.-selected CEA grcups in response to sj

, Revision C0 Page 5 of 19 '

c j.[ [ _

l

i I either a large load ajection or loss of one feedwater pump, withcut 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 l the information that an RPC is in progress, and a more accurate dcwn- f power transient ca'.culation in the event of an RFC. In addition, the [

positive range limit of the addressable constants for the DNBR and LPD f penalty factor nultipliers is being shifted toward zero to cover more  ;

, completely the range of applicability. These modifications are I i

described in more detail in Reference 4.3.

i The modification process was initiated when details of the  !

modification were established by the responsible C-E engineering i

group. The modifications will be incorporated into a revision to the i CPC and CEAC Functional Design Specifications. Plant-speci fi c h t

constants will be generated for each System 80 plant, and a Data Base

< Document recording these constants will be generated. Since these

! modi fica'. ions impact the CPC/CEAC FORTRAN code, the CPC/CEAC FORTRAM code certification document will be revised. All revisions to the ,

4 Functional Design Specifications and to the FORTRAN code will be done in accordance with the requirements of Reference ?.2. Additional requirements for software functional de:ign changes are described in '

more detail in Reference 4.1.

T r

s 1

i I

i e

i

.I i, ,

Revis'en CO Page 6 of 19 j

__s+g_- , - - -  ;--, - _ -

2.0 IMPLEMENTATION AND TESTING 2.1 SCOPE OF IPPLEMENTATION 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 IMPLEMENTATICN AND DISK GENERATION All algorithm changes will be documented on Sof tware Change Requests (SCR) and will be transmitted to the sof tware implementation group.

The procedures for filling out and processing ar SCR are covered in more detail in Reference 4.1. The most recent revisions of CPCS Sof tware Specifications will be revised to reflect all sof tware 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 Systen 80 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

, inplementation of modifications to the CPCS sof tware and the generation of a new set of program constants. Phase I testing is performed on relatively small, single-entry / single-exit segments of code called nodules as well as for integrated nodules which constitute individual programs. Test cases will be generated for each and every module and for progran-wide testing.

Except for Phase I testing of the CPCS Executive sof tware, all test cases will be transmitted to the functional cesign grcuo which will Revision 00 Page 7 of 19 l

i 1

execute the test cases with the CPC/CEAC FORTRAN code. The results will then be returned to the software implementation grcup 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 folicwing 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 for each System 50 plant in the Phase I Test Report.

4 2.4 PHASE II TESTING Phase II testing consists of the following tests:

1 1 ( 1) Input Sweep Test,

( 2) Dynamic Sof tware Verification Test, and

( 3) Live Input Single Paraneter Test.

These tests are perforned 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 a.1.

The Phase II testing uses the CPC/CEAC FDPTRAN code as a casis for comparison and for generating acceptance criteria. The results oi the Phase II testing will be documented for each System 30 plant in the Phase II Test Report.

. 2.4.1 Input Sweeo 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 i values read f rcn a storage device. The objectives of the Input Sweep Test are described in Reference J.1 and are summarized below:

i (1) To determine the processing uncertainties resulting frcn f

differences in nachine orecision between the CPC/CEAC system Revision 00 Page 8 of 19

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.

l (2) To verify the ability of the CPCS sof tware algorithms to [

L initialize to a steady state after an Auto-Restart for each test l case.

• i (3) To complement chase I individual module and progran-wide testing A

by identifying any abnormalities which were not uncovered p revi ou sly .

The Input Sweep Test will be performed in two segnents. The CPC l

software and the CEAC software segments will be independently tested.

Each segment will have its own test cases and acceptance criteria for processing uncertainties. Each segment will be first executed on the '

CPCS sof tware by the sof tware-implementation group. The test cases

] will be allcwed to initialize _by convergence of critical calculated parameters, af ter which calculated parameter values will be I

transferred to the fune-ional design grcup. The functional design group will execute the same test cases on the CPC/CEAC FORTRAN code and will then perform a comparison between the two sets of calculated

. parameter values. Part of this comparison will be a statistical evaluation wnich will generate the processing uncertainties. The i

results of this cenpariscn will be evaluated to ensure the test objectives have been met. >

2.4.2 Dynamic Sof tware Verification Test (DSVT)

The Dynanic Sof tware Verification Test is a real-time exercise of the [

CPC application sof tware and executive sof tware with transient CPC  !

input values read frca a storage device. The objectives of the DSVT i

] are described in Reference d.1 and are sumnarized belcw:

l t

Revision 00 Page 9 of 19  !

w m

.s

! (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 l

i correct implementation of the software modifications.

i i .

The DSVT cases will be executed on the CPC/CEAC FORTRAM code to 3

generate the acceptance criteric. The DSVT cases will then be execu ted on the CPCS sof tware. 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 sof tware. The results of this test will be compared with the acceptance criteria and i

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 j external signal generator and read through the CPCS input hardware.

The objectives for the LISP test are described in Reference 4.1 and a re summa ri zed belcw:

, (1) To verify the dynamic response of the integrated CPCS software

., and hardware.

l 1

(2) To supplement other Phase I and Phase II tests in assuring l

correct implemen'.ation of the so/tware modi fications.

(3) To evaluate the integrated hardware /sof tware system during operational modes, 4

The LISP test cases will first be executed on the CPC/CEAC FORTRAN code to generate the acceptance criteria. The LISP test cases will then be executed using the CPCS sof tware. Dynamic test case inputs

-will be generated by an external signal generator to produce " live

Revision 00 Page 10 of 19

I i

i analog and digital signals that are input to the CPCS input processing hardware. Each LISP test case will vary only one input paraneter, l holding the other inputs at constant values. The LISP test also exerci es all dynamic portions of the CPCS software algorithms. The results of this test will be compared with the acceptance criteria and j evaluated to ensure the test objectives have been met.

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

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 ange limits for all addressable constants will be tested j and verified as having been correctly implemented. Finally, all i aspects of automated reentry of addressable constants will be tested i

and verified to be correctly implemented.

4 j 2.5 PHASE I TEST CASE SELECTION Af'D ACCEPTANCE CRITEP.I A j For Phase I testing, test case's will be generated for ail modules.

These test cases will include cases to exercise all modifications, j including those related to RPC. The selection of test cases.will j ensure that each functional branch and each instruction in all modules l will be exercised. Program wide test cases will then be run to assure carrect transfer of information between modules of the same program and compatibility of the ROC modifications.

i The acceptance criteria will be allowable di f ference between the expected results and the actual results. Mcwever, all differences greater than shall be investigated, and their causes verified as not being due to sof tware errors or corrected.

2.6 PHASE II TEST CASE SELECTION i

i THE CPC Input Sweep Test cases are selected to cover the region of CPC I cperation. Approximately test cases will be generated. Test 2

Revision 00 Page 11 of 19

f i  !

i i

{ case parameters will be varied over the range of CPC inputs with the  ;

t 4

folicwing additional variations applied over certain test case ranges: j i r i

t t j-  !

(

i I 4

i 4

r l

I  !

i i

i i j '

l The CEAC Input Sweeo Test cases are selected to cover various CEA ,

j configurations. Approximatelyf test cases will be generated. The

! majority of these test cases will encompass the CEA configurations e 4

i expected during normal operation. The test cases in this first group i a i

1 I  !

. t l

4

?

l _

i l Test cases in the secord group will cover the following conditions:

1 i

i i . 4 i !

. I' i

i' i

l l

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 dynanic portiens of the CPCS application sof tware. 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 sof tware 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 f which are progressing normally and do not require a trip.

The LISP test cases are selected to demonstrate that the integrated CPCS hardware /sof tware system- functions as designed in response to externally-generated transient input signals in a real time envi rcoment. 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.

1 Revision CO Page 13 of 19 l

1 L . . . .

'- I i

TABLE 2.6-1 i Dynamic Sof tware 'lerification Test Cases 5

h t

i k

1 4

i J

4

i l

i 1 l

, i

, i 4

i t

2 i

I. ---

t a

1 1

1 I

Revision 00 .:-co

= :- p . e, p.

? -

f

- 4.--- --,.a- , , - --... -- ** = e. . _.- - ,.,,---.r--- . - - . , - --- ---- . - - - - .-r.- ,

+e---. . --. --------,wwy .- .. ,- - , . . , -w.y - - , - , , _ , -

j TEL E 2.6-1 (Cont. )'

SINGLE VARIABLE 1

4 f

i i

f s

h i

il I

t' 4  ;

i ,

( )

i 3

d-

i 1

f.

i i

1 i

Revision 00 Page 15 of 19

2.7 GENERATION OF PHASE II ACCEPTANCE CRITERI A The acceptance criteria for the CPC Input Sweep test are that:

(1) The processing uncertainties fall within the guidelines described i n Reference 4.1, (2) Initialization capability is demonstrated, and (3) No software errors are detected.

This test will be performed on the CPC sof tware and the CDC 7600 The

! CDC 7600 will then compare the results from both executions, case by case, evaluate the magnitude of the di fference 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 on the CEAC software and the CDC 7600. Comparison and evaluation of results l will be performed in a manner similar to that for the CPC Input Sweep l Test.

The DS'/T acceptance criteria are based on

] . The acceptance criteria for l ]willbe -

determined by ipplying the processing uncertainties determiied during c

CPC Input Sweep Testing to l-l cal cula ted with the CPC/CEAC FORTRAN code. To determine acceptance 7riteria for

. The dynamic cases will then be run on the CPC/CEAC FORTRAN ccTc to produce

. . , acceptance c ri *.eri a.

The acceptance criteria for the LISP test will consist of I

Revision 00 Page 16 of 19

I a

will be factored into the acceptance j criteria. Each case will be executed several times on the CPC/CEAC FORTRAtt code to generate the acceptance criteria.  :

r 1

i l

l i.

I i

i i

t

$ (

i i

l t

k i

i L

i Revision 00 Page 17 of 19

3.0 GENERATION OF MASTER DISK AND SOFTWARE DESIGN DCCLMENTATION I

The generation of a reference disk for Phase I and Phase II testing i 1

was described in Secticn 2.2. Once the testing is satisfactorily I

completed, the two reference disks described in Section 2.2 will ,

I become the new reference disks for the software system. Additionally,  :

several steps will be taken in generating various sof tware disks which i will produce individual channel System Load Disks and System Test

! Di sk s. Four System Load Disks and four Systen Test Disks will be transmitted to each plant.

During the sof tware 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 (1) CPC/CEAC Data Base Document (2) Phase I and Phase II Test Reports

( 3) CPC/CEAC Sof tware Modi fications Document (Reference J.3) l 1

i Revision 00 Page 18 of 19

4.0 REFERENCES

4.1 CPC Protection Algorithm Sof tware Change Procedure, CEN-39( A)-P, Revision 02, and Supplerent 1-P, Revision 00.

J.2 Quality Assurance of Design Manual for C-E Nuclear Pcwer Systems.

4.3 CPC/CEAC Sof tware Modifications for System 80, Enclosure 1-P of this s ubmi t tal .

Revision 00 Page 19 of 19

SYSTEM 80 COCV.ET STN-50 270F t

ENCLOSURE 2-ND TO LD-82-039 CPC/CEAC PROTECTIO,'! .2LG09ITHM TEST PLAN MARCH, 1982 Ccnbustico Engineering, Inc.

Nuclea r P cwe r Systens Dowe r Sys'.em Grcu p

'dindsor, Cconecti cu!

/ t, ,

r sJ

_ POWER d=7s SYSTEMS

m. 1 c., m me.., ..c

LEGAL NOTICE i

i

) ibis report was prepared as an acccunt of work sponsored by

! Conbustion Engineering, Inc. Neither Ccnbustion Engineering cor any person acting on its behalf:

i A.

Makes any warranty or representation, express or j ,

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 l of any information, apparatus, method, or process disclosed in this recort may not infringe privately owned rights; or B. Assumes any liabilities with respect to the use of, or 4 for damages resulting from the use of, any information, j apparatus, method or process cisclosed in this report.

i I

i.

i -

4 e

1

.i 4

f f

4 j

i i

4 I

i i

I i

--y

l ABSTRACT i

i This document presents the approach that will be taken for testing and l

! certifying the CPC/CEAC System Sof tware for the System 80 plants. Sections  !

i

in this document describe the purpose and scope for testirg, types of t l testing to be performed, and documentation to support the algorithm changes f

and test results. The testing will be performed in accordance with the [

t l) procedures of CEN-39( A)-P, Revision 2 and Supplement 1-P, Revision 00.  ;

! Specific tests which are being performed because of the changes being made r

! l to the algorithms are specifically discussed.  !

, i j

t k

)

l l <

! i i

t

~

i  !

i l

?

J I l-  !

2

I

f I

l

! i i

i i

i i

i i

i i

i l

l, r Revision 00 Page 3 of 19 j r

l

1 1

TABLE OF CONTENTS Section Title Page No. '

! 1.0 SPECIFICATION FOR TESTING PROTECTION ALGORITHM 5 1.1 PURPOSE 5-1.2 SCOPE 5 1

1.3 MODIFICATION RECUIREMENTS 5 2.0 IMPLEMENTATION AND TESTING 7 l 2.1 SCOPE OF IMPLEMENTATION AND TESTING 7 2.2 IMPLEMENTATION AND DISK GENERATION 7 i

2.3 PHASE I TESTING 7 2.4 PHASE II TESTING 8 2.4.1 Input Sweep Test 8 2.4.2 Dynami c Sof tware Verification Test (DSVT) 9 2.4.3 Live Input Single Parameter (LISP) Test 10 2.5 PHASE I TEST CASE SELECTION AND ACCEPTANCE CRITERI A 11

2.6 PHASE II TEST CASE SELECTION 11 d

2.7 GENERATION OF PHASE II ACCEPTANCE CRITERI A 16 1 3.0 GENERATION OF MASTER DISKS AND SOFTWARE DESIGN DOCUMEhiAfiON 18 a.0 REFERENCES 19 i

LIST OF TABLES Table No. Titl e Page No.

2.6-1 Dynamic Software Verification Test Cases la i

Revision C0 Page 4 of 19

.~. - _ . . - _ , _ - _ - _ _ _ - . . . _ . - . _ . - -_. .. - . _ - - _ _ . - _ _ _ - -

1.0 SPECIFICATION FOR TESTING PROTECTION ALGCRITHM 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) sof tware .

. for the System 80 plants. The testing outlined here is described in more detail in Reference d.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 a.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 sof tware for each System 80 plant will be considered complete with the formal

! issuance of the follcwing plant-snecific documents:

1

1. CPC/CEAC Data Base Document 4

2. The Phase I Test Report

3. The Phase II Test Report 3

j 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 a.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 software specification and implementation for l

System 80.

j 1.3 PODIFICATION REQUIREPENTS The nodifications being made to the System 80 C?CS sof tware are to l upgrade the CPCS capabilities to be compatible with the Reactor Power j Cutback System (RPCS). The RPCS is designed to rapidly. reduce the

! reactor pcwer by drcpping pre-selected CEA groups in response to Revision 00 Page 5 of 19

either a large load rejection or loss of one feedwater pump, without tripping the plant. These modifications ccnsist 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 dcwn-power transient caluuiation in the event of an RFC. 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 modi fications are described in more detail in Reference 4.3.

i The modification process was initiated 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. Pl ant-speci fi c constants will be generated for each System 80 plant, 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 d.1.

.I l

i I

Revision CO Page 6 of 19

- - - -- - , , , , , , , - , - . _ . - _c <-- ~,-_ _s -

- -- -,--,v, , - , - - - - - -

i 2.0 IMPLEMENTATION AND TESTING t

i 2.1 SCOPE OF IMPLEMENTATION AND TESTING 1 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 Sof tware 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 Sof twcre Specifications will be revised to reflect all sof tware modifications indicated by the SCR's, and the resulting documents will be reviewed in accordance with Reference a.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 Systen 80 project disk. The object modules will then be fully debugged. Once debugged, '

the project disk will be used to cenerate 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 ,

I Phase I testing will be performed to verify the correct implementation of modifications to the CPCS sof tware and the generation of a new set of program constants. Phase I testing is performed on relatively snall, single-entry / single-exit segments of code called modules as well as for integrated modules wn4ch constitute individual programs. Test cases will be generated for each and every module and for progran-wide testing.

Except for Phase I testing of the CPCS Executive sof tware, all test. 1 cases will be transmitted to the functional design group which will l

Revision 00 Page 7 of 19 i 1

execute the test cases with the CPC/CEAC FORTRAN code. The results will then be returned to the software implementation group which will execute the test cases on the CPCS software and compare the results with those from the FORTRAN code. The CPCS executi ve sof tware will be l

tested following any change made to it by comparing actual and expected hand-calculated results for selected test cases. These ccmparisons 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 for each System 80 plant in the Phase I Test Report.

2.4 PHASE II TESTING Phase II testing consists of the follnwing tests:

(1) Input Sweep Test,

( 2) Dynamic Software Verification Test, and (3) Live Input Single Paraneter Test, a

f .

These tests are performed on a single channel CPC/CEAC syst em with integrated sof tware that has undergone successful Phase I tesiing.

i The objectises of Phase II testing are described in Reference 4.1.

The Phase II testing uses the CPC/CEAC FOPTRAN code as a basis for ccmparison and for generating acceptance criteria. The results oi the Phase II testing will be 'ocumented for each System 80 plant in the Phase II Test Report.

2.4.1 Inout Sweeo Test The Input Sweep Test is a real-time exercise of the CPCS application program software 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 belcw:

i (1) To determine the processing uncertainties resulting f rcn ,

1 l differences in nachine precision between the CPC/CEAC system l Revision 00 Page 8 of 19 l

v-- ,- w ,y----- - - - - g- , --,,-- ,,,,y- ,eq

[ hardware and the CDC 7600 (on which the FORTRAN code is i

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 p revi ou sly .

The Input Sweep Test will be performed in two segnents. The CPC sof tware and the CEAC sof tware segments will be independently tested.

Each segment will have its own test cases and acceptance criteria for processing uncertainties. Each segment will be first executed on the CPCS sof tware by the sof tware-implementation group. The test cases will be allcwed to initialize .by convergence of critical calculated parameters, af ter 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 then 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 enc 2re 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 telow:

Revision C0 Page 9 of 19

(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 sof tware 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 sof tware. 11put values for each test case will be read from a storage device. Alter 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 tne 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 sof tware, 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 a.1 cnd are summarized belcw:

(1) To verify the dynamic response of the integrated CPCS sof tware and hardware.

(2) To supplement other Phase I and Phase II tests in assuring correct implementation of the sof tware modi fications.

(3) To evaluate the integrated hardware /sof tware system during l operational modes.

The LISP test cases will first be executed on the CPC/CEAC FORTRAM I code to generate the acceptance criteria. The LISP test cases will then be executed using the CPCS sof tware. Dynami c test case inputs will be generated by an external signal generator to produce " live" Revision 00 Page 10 of 19

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 I 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.  ;

i 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 I checked to ensure that the Point ids displayed on the operator's  :

module are the same as those listed in the Point ID tables. Tha l ower i and upper range limits for all addressable constants will be tested ,

and verified as having been correctly implemented. Finally, all f aspects of automated reentry of addressable constants will be tested and verified to be correctly implemented. l l 2.5 PHASE I TEST CASE SELECTION AND ACCEPTANCE CRITERIA i For Phase I testing, test case ~s will be generated for all modules.  !

These test cases will include cases to exercise all modifications, I i

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. Program wide test cases will then be run to assure i correct transfer of information between modules of the same progran f and compatibility of the RPC modifications.

The acceptance criteria will be allowable di f ference

. between the expected results and the actual results. Hcwever, all l

differences greater than shall be investigated, and tneir i t

causes verified as not being due to sof tware errors or corrected.

{

2.6 PHASE II TEST CASE SELECTION THE CPC Input Sweep Test cases are selected to cover the region of CPC l

cperation. Approximately test cases will be generated. Test l l

Revision 00 Page 11 of 19

f .

1 case parameters will be varied over the range of CPC inputs with the folicwing additional variations applied over certain test case ranges:

1, 1

l 1-i i

1

The CEAC Input Sween Tes+ cases are selected to cover various CEA

.i configurations. Approximately ]testcaseswillbegenerated. The

{ majority of these test cases will encompass the CEA configurations j expected during normal operation. The test cases in this first group

~

l 1

l

,i j

I 1

I i

I l _

Test cases in the secord group will cover the follcwing conditions:

! r i

k a

i i

i i

t i

1

Revision 00 Page 12 of 19

, , - - .- , , <, - . , , - . . ~ , .-- --, ,

Because of the static nature of the CEAC Input Sweep Test, oc 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 RFC. These test cases will verify that the CPCs respond correctly during a RPC event

^

i 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 /sof tware system- functions as designed in response to externally-generated transient input signals in a real time e nvi ronment. The test cases will consist of variations of single variables encompassing cases 17 through 21 of Table 2.o-1. Since the LISP test evaluates trip time based on transient input signals, no RPC-related test cases are included in this test.

Revision 00 Page 13 of 19

~

( l 5 { ;. .

w

?' ,

/ TABLE 2.6-1 l .

s.

1 - >

Cynamic Sof tware Verification Test Casas k.

e -

1.

r

/

J pc ,

1 -  ;

?:.-

/-

t

\

I

/

A

)

\

.i [

i

\.

i ,

4. ;

r i.

i

't i

' I I

I t

i x

l ,

._f t

L s

- . i P.svisien 00 p3co 12

- v 2, ,i e.

l

_- ______m_____._

1 TA?LE 2.6-1 (Cont. )

S!!!GLE '/ARI; ELE 1

9 f

I t

1, 8

i Re'/ision 00 p3gg 75 gf )g l

I i

f 2.7 GENERATION OF PHASE II ACCEPTANCE CRITERI A t

4 The acceptance criteria for the CPC Input Sweep test are that:

(1) The processing uncertainties f all within the guidelines described

] it. Reference 4.1, (2) Initialization capability is demonstrated, and l

(3) No software errors are detected.

.I i

l This test will be performed on the CPC software and the CDC 7600. The l CDC 7600 will then ccmpare the results from both executions, case by l case, evaluate the nagnitude of the dif ference between calculated 1

l DNBRs and LPDs, and generate processing uncertainties.

The acceptance criteria for the CEAC Input Sweep test are similar to

+ hose for the CPC Input Sweep Test. The test will be performed on the i

j CEAC software and the CDC 76CO. Ccaparison and evaluation of results I will be performed in a manner similar to that for the CPC Input Sweep i

, Test.

1 1

l Tne DSVT acceptance criteria are based on j . The acceptance criteria for l- ,will be ._ ,

l determined by applying the processing uncertainties determined during CPC Input $ weep Testing to p

] Cal cul ated

with the CPC,4EAC F0PTRAN coco. To determine acceptance criteria for i _.

4 1

. . The i - - ,

j . dynamic cases aill then be run on the CPC/CEAC FORTRAN coce to produce '

i

acceptance criteria. l 1 '- .  !

The acceptince criteria for the LISP test will consist of; 1 .- _

! Revision CO Page 15 of 19

l will be factored into the acceptance ,

l ~

I b 'c ri t e ri a . Each case will be executed several times on the CPC/CEAC FORTRA.l code to generate the acceptance cri*.eria.

[

t 1

i l

t i

t i

I i

i i 1

t i'

l l

a I i

I l

f i

i l

1

)

t i

1 i

1 I

l i

i

!- Revision CO Page 17 of 19 I

l 1

I

! l l 3.0 GENERATION OF MASTER DISR AND SOFTWARE DESIGN DCCLMENTATION >

The generation of a reference disk for Phase I and Phase II testing ,

I was described in Secticn 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 sof tware system. Additionally, several steps will be :aken in generating various software disks which f j will produce individual channel System Lcad Disks and System Test  !

Disks. Four System Load Disks and four System Test Disks will be  ;

t transmi tted to each plant, i.

4 During the sof tware 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 j documents will include:

i 4

(1) CPC/CEAC Data Base Document l

i (2) Phase I and Phase II Test Reports (3) CPC/CEAC Sof tware Modi fications Document (Reference c.3) i ,

n 9

4 i

r 1

(

i t l

l l

l l

4 i Revision 00 Page 18 of 19 l 1

.. . - - . .. - .. - . _......_.~ . . -

~

l

! i 4.0 R EFEPE! ICES l

l i

4.1 CPC Protection Algorithm Sof tware Change Procedure, CEN-39(A)-P, i Revision 02, and Supplement 1-P, Revision 00. ,

I I

4.2 Ouality Assurance of Design itanual for C-E Nuclear Pcwer Systems.  !

f I

i i 4.3 CPC/CEAC Sof tware Modifications for System 80, Enclosure 1-P of this  !

i 3

s ubmi t tal . ,

i i 1

I 1 '

4 0

i  !

4  !

j f 6

i t

j 1 i i  !

l i

i,  !

1 4

i

! i I  !

i I i t

i t

, e f

i .  !

4 i

4 5

a j .

Revision CO Page 19 of 19

. _ _ _ _ , - . _ . - - _ . _ _ . . -. __. _ .__.-._- _..._ ... _ ... _ ._.._.,,. _ _ __. ..--..__ __.-- . . _ _ . . . . - . . _ _ , . _ _ . -