ML20095F924

From kanterella
Jump to navigation Jump to search
Nonproprietary Version of Rev 0 to Cpc/Ceac Sys Phase II Software Verification Test Rept
ML20095F924
Person / Time
Site: San Onofre  Southern California Edison icon.png
Issue date: 03/31/1984
From:
ABB COMBUSTION ENGINEERING NUCLEAR FUEL (FORMERLY
To:
Shared Package
ML13309B441 List:
References
CEN-269(S)-NP, CEN-269(S)-NP-R, CEN-269(S)-NP-R00, NUDOCS 8408270412
Download: ML20095F924 (25)


Text

.. . - . . . - . . . . . . - . - . - .

~

SONGS NUCLEAR ONE - UNIT 2 DOCKET 50-361 and 50-362 CEN-269(S)-NP REVISION O CPC/CEAC SYSTEM PHASE II SOFTWARE VERIFICATION TEST REPORT l MARCH 1984 l .

\

l l

l J .

l *- .

COMBUSTION ENGINEERING, INC.

Nuclear Power Systems Power Systems Group Windsor, Connecticut 8408270412 840001 PDRADOCK05000g P

LEGAL NOTICE This response was prepared as an account of work sponsored by Combustion Engineering, Inc. tieither Combustion 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, er usefulness of the infomation contained in this rcsponse, or that the use of the information contained in this response, or that the use of any infomation, apparatus, method, or process disclosed in this response, or that the use of any information, apparatus, method, or prccess disclosed in this response 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 response.

i

}

l l

e l .

r l

l l

l Page 2 of 25

y. , ,-,.,., .- . ,,yp-.. ---e-,--,-._-.e,gp.y,-_ypy_y._p.,,.-.

. m.,,9_9ym.,-- - - -.wy,.-,.,, , .p_ ,_ .,-, , , _ - ,, , , ,- , , _ .,, , , . , ,,.._ - - _ ._ - . _ ,---_,, . ,

^

1 I

~

ABSTRACT Phase II Testing is performed on the CPC/CEAC System to (1) verify that the CPC and CEAC software modifications have been properly integrated with the CPC

. and CEAC software and system hardware and (2) provide confirmation that the static and dynamic operation of the integrated system as modified is consis-

, tent with that predicted by design analyses, which provide design inputs to CPC/CEAC Functional Design Specifications. -

This report presents the Phase II test results for the San Onofre Nuclear

, Generating Station Unit 2 Plant CPC/CEAC Revision 02 software.

The Phase II Software Verification Tests have been performed as required (Reference 1). In all cases, the test results fell within the acceptance criteria, or are explained. The test results are that both the CPC-and CEAC software have no indication of software error and that the operation of the integrated system is consistent with the perfonnance predicted by des.ign analyses.

. l 4

l 1

~

l i

l l

Page 3 of 25

~

__ _ . _ - --.. l TABLE OF CONTENTS I

l Section Title Page No. l l

1.0 INTRODUCTION

5 j 1.1 Objectives 5 l

~

1.2 Description of Phase II Testing 6  !

1.3 Applicability 6 i

2.0 CPC/CEAC INPUT SWEEP TESTS 7 2.1 CPC Input Sweep Test Case Selection 7 2.1.1 CPC Processor Uncertainty Results 7' 2.1. 2 Analysis of CPC Input Sweep Test Results 8 2.2 CEAC Input Sweep Test Case Selection 9 2.2.1 CEAC Processor Uncertainty Results 9 2.2.2 Analysis of CEAC Input Sweep Test Results 10 3.0 DYNAMIC SOFTWARE VERIFICATION TEST 11 3.1 DSVT Case Selection 11 3.2 Generation of DSVT Acceptance Criteria 12 3.3 Analysis of DSVT Results 18 4.0 LIVE INPUT SINGLE PARAMETER TEST 21 4.1 LISP Test Case Selection 21 4.2 Generation of LISP Acceptance Criteria 21 4.3 LISP Test Results 22 5.0 PHASE II TEST RESULTS

SUMMARY

24

6.0 REFERENCES

25 Page 4 of 25

- - - - -.,.,- -,. - *...---wa- m-- ,*w---- e--e m -ewe- - - - *- g-we. w.=-w e w

~

1.0 INTRODUCTION

f The verification of software modifications of the CPC/CEAC System consists of several steps which address two major areas of the modification process:

(1) Specification of software modifications (2) Implementation of software modifications The specification of software modifications is doct.mented in the

. Software Change Procedure (Reference 1), CPC and CEAC Functional

, Design Specifications (References 2 & 3), and the Data Base Listing, and is verified by design analyses contained in recorded calculations. The implementation of software modifications is documented in Software Design Specifications 'and assembly listings (Reference 4).

The verification process for the modified software implemen.tation is two-phase: Phase I testing (Reference 5), must be perfomed before Phase II. Phase I' testing, which was successful, verified the correct implementation.of the modified software. Phase II testing completes the software modification process by verifying that the integrated CPC System responds as expected.

, This document contains the test results and conclusions for the Phase II software verification test..

1.1 Objectives *

~

The primary objective of Phase II testing is to verify that the CPC ,

and CEAC software modifications have been properly integrated with-

. the CPC and CEAC software and system hardware. In addition, Phase II testing provides confirmation that the static and dynamic operation of the integrated system as modified is consistent with that predicted by design analyses. These objectives are achieved by Page 5 of 25

.,_, e.. nw..s~+ee+.-- -*--n s=

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

..-:-- - 2 ::---}

^

comparing the response of the integrated system to the response predicted by the CPC/CEAC FORTRAN Simulation Code. This comparison is performed for a selected range of simulated static and dynamic input conditions.

. 1.2 Description of Phase II Testing Phase II testing consists of the following tests:

(1) Input Sweep Tests for the CPC and the CEAC, (2) Dynamic Software Verification Test, and (3) Live Input Single Parameter Test.

These tests are performed on a single channel CPC/CEAC System with ntegrated software that has undergone successful Phase I testing.

i 1.3 Applicability .

This report applies to the Phase II Testing performed on the San Onofre Nuclear Generating Station Unit 2 CPC/CEAC system software Revision 02.

l

  • 1
  • j l

N j i

l l

I Page 6 of 25

, - . . , . . , _ , .,-,__.-.,,,,.a. _ _ _ . , . , . _ , , . . , _ , .. ., ,. . , , . _ ,,,_,,,,_._,,,-,___,..g.,..,,,,..,

^

I __ _._ _. ___

s 2.0 CPC/CEAC INPUT SWEEP TESTS The Input Sweep Test is a real-time exercise of the CEAC and CPC application and executive software with steady-state CPC and CEAC input values read-from a storage device. These tests have the

. following objectives:

(1) To detemine the processing uncertainties that are inherent in the CPC and CEAC designs. -

(2) To verify the ability of the CPC and CEAC algorithms used in

, the system hardware to initialize to a steady state after an auto-restart for each of a large number of input combinations within the CPC/CEAC operating space.

(3) 'To complement Phase I om dule testing by identifying previously unnoticed abnormalities in the CPC and CEAC algorithms used in the system hardware 2.1 CPC Input Sweep Test Case Selection

[ . 7 cases, each involving different combinations of process inputs and addressable constants, were used for CPC design qualification testing of the Revision 02 software.

2.1.1 CPC Processor Uncertainty Results For each test case, differences in the results of the FORTRAN

~

simulation code and CPC system were calculated. A statistical .

analysis of these differences produced the processing uncertainties. ,

The %BR statistics did not include those' cases for which the DN8R ascalculatedoneithersystemwasatthelimits[ J. This is because a difference of zero (or close to zero) would be computed and would incorrectly weight the distribution of differences. A Page 7 of 25

- - - - . - , , w a.., , , , - - , e, -,,.,,,--w.m- ,.ymm-n-.,w-m,,,-r-e-n.m-~+,..---rm,m.mn_myn,-e w-~w,,-,

-q

....,,m.,. -

l l

~

total of f leases remained after these cases were eliminated. The i LPD statistics did not include those cases for which the LPD as calculated on either system was equal to or greater than the upper limit of f .7 core average kW/ft (= f .7 kW/ft). A total of f J cases remained after these cases were eliminated. .

~

Although [ .lcases were not included in the computation of DN8R and LPD statistics, respectively, they were still included as Input Sweep Test cases for the purpose of identifying potential software errors.

The processor uncertainties for DNBR and LPD are defined as the one-sided tolerance limits which encompass 95% of the distribution

~

of DN8R and LPD differences for all test cases with a 95% confidence level. The processor uncertainties detemined from Input Sweep for DN8R and LPD, respectively, are C - 2 '

DNBR u~ nits, and f . Jcore average kW/ft.

However, since the distribution of differences is so restrictive, i the maximum error may be used (that is, the limits which encompass 100%ofthedifference). This is more conservative and yet still results in small processor. uncertainties. Thus defined, the processor uncertainties (for Revision 01 of the CPC Input Sweep tests) on DN8R and LPD are [ / DNBR units and E 1 core average kW/ft, respectively.

2.1.2 Analysis of CPC Input Sweep Test Results~ ,

l The results of the test cases exceeding the 95/95 tolerance limit j were analyzed for evidences of software errors. The review results

of the DNBR and LPD test cases outside the 95/95 tolerance limit will now be discussed. For DNBR there were Ocases below the lower

. tolerance limit of T f(DNBR units) and[./ test cases above the upper tolerance limit of [ [(DNBRunits). For these[f test cases the difference between the single channel and the CPC Fortran is within the accuracy of the two systems. The

largestpercenterroramongthe[fcaseswas[ J.

Page 8 of 25 4 .

_~ . ._ ._

j

~

These differences do not'show a significant conusonality since the differences are absolute (not relative) and it shot:1d be expected that the largest differences should occur at high DNBRs. It is therefore concluded that no errors are indicated in the CPC Single Channel DNBR program.

. 1 For LPD the cases examined were:[lcases with differences below the lower 95/95 tolerance limit of f J(%ofcoreaverage j kW/ft),[/ cases with differences greater than the upper tolerance limit of f J. .

. The largest percent error among the (Jcaseffwas f _7. The

/

comnion input to these test cases was foua.d in other test cases with less maximum difference and less perdnt error. Examination of the inputstoall[./LPDcasesoutsidethetolerancelimitsshowedthat l the 1'nputs covered a wide spectrum. No conuson area was found. It is therefore concluded.that there is no indication from the Input

! _ Sweep test results of software errors in the Single Channel,calcula-1 tion of LPD.

i

2.2 CEAC Input Sweep Test Case Selection

]

I -

7 est t cases, each involving different combinations of CEAC process inputs were used for CEAC design qualification testing of the Revision 02 software. These test cases covered all CEAC

, operating space.

4 2.2.1 CEAC Processor Uncertainty Results

=

For each test case, differences between the CEAC FORTRAN simulation ,

code and CEAC single channel systen: results were calculated. The

. processor uncertainties for DN8R and LPD 'are defined as the one-sided tolerance limits which encompass 95% of the distribution of j DNBR and LPD penalty factor differences for all test cases with a 95% confidence level.

l l

t Page 9 of 25

- - . -- - . . , - . - - , .,--~.---.,,,.m-,,,..,,,-w.-,r..m-.,e, .,%w - w .qm -# .w.,%,,~,.--ww-,,.,,,,,.,y w- - .

Tre processor uncertainties for the DNBR and the LPD penalty factor differencesare[ '

JDNBRunitsand

[ JcoreaveragekW/ft, respectively.

. 2.2.2 Analysis of CEAC Input Sweep Test Results The results were reviewed for representativeness and for any evid-ence of computational differences between the CPC FORTRAN simulation and the Single Channel Facility (SCF). The test data produced penalty factors ~which swept the respective DNBR and LPD penalty factor ranges with emphasis on the midrange values. The differences between the pen'alty factors from the SCF and the FORTRAN simulation were within a range which is justified by the differences in word length.

- 3-In conclusion, the CEAC Input Sweep Test result did not indicate the existence of a software error.

l . .

I I

l Page 10 of 25 l

- - - - 1

. 1

' ~

I-3.0 DYNAMIC SOFTWARE VERIFICATION TEST

, The Dynamic Software Verification Test (DSVT) is a real time exer-cise of the CPC application software and executive software with transient CP.C input values read from a storage device. This test <

. has two objectives:

(1) To verify that the dynamic response of the integrated CPC software is consistent with that predicted by design analyses,

~

. and i

(2) To supplement design documentation quality assurance, Phase I module tests, and Input Sweep Tests'in assuring correct imple-mentation of software modifications.

Furth~er information concerning DSVT may be found in Reference 1.

3.1 DSVT Case Selection Test cases for DSVT are selected to exercise dynamic portions of the CPC software with emphasis.on those portions of the software that have been modified.

, DSVT requires that, as a minimum, cases [ .7 be selected for testing. These cases are from the Phase II test series and consist of a f C

respectively. Because the changes made for this softivare i revision were limited to the CEAC portion of the data base, it was . l l- . only necessary to perform a subset of the entire battery of DSVT ,

l cases listed below. Therefore, in addition to the minimum group of

.- cases required, those others containing CEA deviations were also conducted [ J. Also, one test case [ J, which was

+

l 2

Page 11 of 25 1

    • *" ' ' * ~

" . . __ ..; T

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

_ ~_. _~~ . . _ _ _ _

~

desigred to test a feature of the Reactor Power Cutback System installed in some other C-E plants, was included because it demonstrates the proper [ ]

[ I -

. 3.2 Generation of DSVT Acceptance Criteria Acceptance criteria for DSVT' are defined (in Reference 1) as the trip times and initial values of DN8R and LPD for each test case.

These trip times and initial values are generated using the certi-fied CPC/CEAC FORTRAN simulation code. Processing uncertainties obtained during Input Sweep testing are factored into the acceptance criteria for initial values of DNBR and LPD where necessary. Trip times are affected by program execution lengths as well as by the Input Sweep uncertainties. The minimum, average, and maximum execution lengths (in milliseconds) calculated for the Revision 02 software are listed below.

CP'. Application Program Execution Lengths j Program Minimum Average Maximum 4

(msec) (msec) (nsec) 1 FLOW l UPDATE POWER j STATIC

~

l Each DSVT case is initially executed once with nominal program l

. execution lengths (values between the minimum and maximum) and data base values of trip setpoints using the CPC/CEAC FORTRAN simulation code. Following execution of the same cases using the single channel facility, those cases which do not yield trip times I

equivalent to those calculated by the CPC FORTRAN code are re-executed: once with minimum execution lengths and/or the most conservative trip setpoints and once with maximum execution lengths Page 12 of 25

. ' Z . . : Til_lT ~.ii__.___.___._.__.._._______._ _ . _ . _ _ , _

and/or least conservative trip setpoints. This process produces a band of trip times for the test cases which contains the effects of processing uncertainties. The largest band of acceptable trip times will be obtained if the modified execution lengths and adjusted trip setpoints are used simultaneously.

The software DSVT program includes a[7-millisecond interrupt cycle, to check for DNBR and LPD trip signals. This results in a

[f-millisecond-interval limit on trip time resolution which is factored into the acceptance criteria. The following tables contain the final DSVT acceptance criteria for initial values and trip times

, for DNBR and LPD.

l Page 13 of 25

. . . . . =

j l

i Acceptance Criteria for j DNBR and LPD Initial Values (DN8R Units and kW/ft., respectively)

DN8R - DNBR LPD . LPD

. , Test Case (Min.) (Max.) (Min.) (Max.)

Page 14 of 2S

-Acceptance Criteria for M8R and LPD Initial Values (DN8R Units and kW/ft., respectively)

(Continued)

. DN8R DN8R LPD LPD Test Case (Min.) (Max.) (Min.) (Max.)

mud Page 15 of 25

. = , n . . + - -

Acceptance Criteria for DNBR and LPD Trip Times (seconds)

DNBR Trip DNBR Trip LPD Trip . LPD Trip

. Test Case (Min.) (Max.) (Min.) (Max.)

s i

I l

l Page 16 of 25

Acceptance Criteria for DNBR and LPD Trip Times (seconds)

(Continued)

. DNBR Trip DN8R Trip LPD Trip LPD Trip Test Case (Min.) (Max.) (Min.) (Max.)

~

d .

t Page 17 of 25 l

. = - .. _ _ _ _ . _ _ - - - - - . . , _ . - - _ _ . , . _

~

l l

3.3 Analysis of DSVT Results Results of DSVT are listed in the following table.

The trip times for all of the test cases executed.on the Single

. Channel Facility met the acceptance criteria determined by the CPC/CEAC FORTRAN simulation code. Because the trip times on the

, Single Channel Facility were identical to those on the FORTRAN simulation, generation of trip time acceptance bands was not necessay.

For all test caser with the exception of Case , the initial values of DN8R and LPD were within the acceptance criteria.

\

._ 3 no software error is indicated.

1 Page 18 of 25

r- _ _ _ _ . _ _ _ _ _ _

DSVT Results Initial Initial DN8R LPD DNBR Trip LPD Trip Test Case (kW/ft.) (sec.) (sec.)

(DN8R Units)-

Page 19 of 25

.. . ._ w.. .

  • DSVTRESULTS(Cont.)

Initial Initial DNBR LPD DNBR Trip LPD Trip Test Case (DNBR Units)- (kW/ft.) (sec.) . (sec.)

ak 1

i j

1 -

Page 20 of 25


,4- p py_- 4 *m mm-wy

E1___ __ f- ~ ~

~

e . _ .

. 4 w w. ee h-- W -

4.0 LIVE INPUT SINGLE PARAMETER TEST The Live Input Single Parameter test is a real-time exercise of the CPC/CEAC application and executive software, with transient CPC/CEAC input values generated from an external source and read through the

. CPC/CEAC input hardware. The objectives of this test are:

(1) To verify that the dynamic response of the integrated CPC/CEAC software and hardware ir consistent with that predicted by design analyses.

, (2) To supplement design documentation quality assurance, Phase I module tests Input Sweep Tests, and DSVT in assuring correct implementation of software modifications.

(3) 'To evaluate the integrated hardware / software system during operational modes. approximating plant conditions.

4.1 LISP Test Case Selection Reference 1 identifies the. test cases to be used for LISP. These cases are the single variable dynamic transient test cases from the Phase II. test series.

, _ These test cases, which are applicable to SONGS-2, consist of a _

3 ~.

4.2 Generation of LISP Acceptance Criteria The acceptance criteria for LISP are base' d on trip times for the dynamic test cases. For the non-target CEA drop test case, there should be no trip.

Page 21 of 25

.a . . . - ,e,

r . -. - - - - . . . . -

These cases are simulated within the CPC FORTRAN Simulation Code and contain the following adjustment components.

Application program execution lengths used for LISP testing were the same as those for DSVT, with the addition of CEAC minimum and maximum execution lengths of { ] msec,respectively. ,

The final acceptance criteria (generated by the CPC FORTRAN simula-tion code and adjusted for the above components) for LISP are contained in the following table.

Test Case Minimum Trip Time Maximum Trip T,ime (seconds) (seconds) 4.3 LISP Test Results The [ J dynamic transients were executed on the CPC Single Channel

, facility. The recorded trip times (in seconds) for each case are listed in the following table:

I Page 22 of 25

_ -. _ _ _ . ~__ __ __ , _ _ ___ _ _ _ _ _ _ _ . _ _ _ _ . . . _ . _ . _ _ _ . _ _ _ _ _ . . -

i- .

Run t

All recorded trip times met the final acceptance criteria for. LISP.

Major' aspects of the system diagnostic features were verified.

Theseincludethe[ - --

] All aspects of automated reentry of Addressable Constants were also' tested.

e Page 23 of 25

e .. _ . . _ . . _ _.. _ _ _ _ . _ _ _ .

)

5.0 PHASE II TEST RESULTS SIM4ARY The Phase II software verification tests have been performed as required in Reference 1. The test results are that both the CPC and.

CEAC Revision 02 toftware have no indication of errors and that the e operation of the integrated system is consistent with the perfor-mance predicted by design analyses, which provide design inputs to

, CPC/CEAC Functional Design Specifications.

5 i

i I

Page 24 of 25

r. -- ... .. .

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

6.0 REFERENCES

1. CPC Protection Algorithm Software Change Procedure.

CEN-39(A)-NP, Revision 02, December 1978.

2. Functional Design Specification for a Core Protection Calculator, CEN-147(S)-NP . February 1981.
  • 3. Functional Design Specification for a Control Element Assembly Calculator, CEM-148(S)-NP, January 1981.

. 4. CPCandCEACDataBaseListing,CEN-266(5)-NP, Revision 00, January 1984.

5. CPC/CEAC System Phase I Software Verification Test Report, CEN-176(5)-NP, Revision 02, February 1984.

(

1 l .

i f

4 Page 25 of 25

7 1

?

e COMBUSTION ENGINEERING, INC.

t 0 .

\

.f

- - - - - - - - ~ - - - - - - - - - - - - - - - - - - ~ ~ -