ML20151Z052

From kanterella
Jump to navigation Jump to search
Rev 3 to CEN-39(A)-NP, CPC Protection Algorithm Software Change Procedure
ML20151Z052
Person / Time
Site: Palo Verde, Arkansas Nuclear, Waterford, San Onofre, 05000000
Issue date: 01/31/1986
From:
ABB COMBUSTION ENGINEERING NUCLEAR FUEL (FORMERLY
To:
Shared Package
ML19273A867 List:
References
CEN-39(A)-NP, CEN-39(A)-NP-R03, CEN-39(A)-NP-R3, NUDOCS 8602130276
Download: ML20151Z052 (61)
v • d • e


Text

{{#Wiki_filter:: CEN-39(A)-NP REVISION 03-NP CPC PROTECTION ALGODITHM SOFTWARE CPANGE PROCEDURE JANUADY, 1986 Combustion Engineering, Inc. Power Systems Group Nuclear Power Systems Windsor, Connecticut Rev. 03 0602130076 060210 ~~ PDR ADOCK 05000361 P VDR

LEGAL NOTICE This report was prepared as an account of work sponsored by Combustion Engineering, Inc. Neither 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 carticular 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 disclosed in this report may not infringe 'D. L 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 cr process disclosed in this report. g Revision 03 Page 2 of 60

i ABSTRACT This document presents procedures to be followed when specifying and implementing modifications to quality assured CPC/C AC software and documentation. Section 1.0 of this document contains procedures applicable to specifying modifications to the CPC/CEAC software functional design and data base. Section 2.0 of this document centains procedures applicable to implementing and testing changes to the CPC/CEAC system software design and data base. Section 3.0 contains procedures applicable to the creation of project specific software and documentation from the approved generic design. These requirements do not apply to changes involving only the values of the Reload Data Black constants. Guidelines for the impler.catation and verifi-cation of such changes are defined in Reference 1.2.3. Revision 03 Page 3 of 60

TAfLEOFCONTENTS Section Title Pace 90. 1.0 SPECIFICATION OF SOFTWARE FUNCTIONAL DESIGN AND 6 DATA BASE CHANGES 1.1 PePPnSE, SCOPE AND APPLICARILTTY 6 1.1.1 Purcose 6 1.1.2 Scooe 6 1.1.3 Acolicability 7

1.2 REFERENCES

9 1.3 CESIGN INTERFACES AND MODIFICATION RE0VIREMENTS 10 1.3.1 Desion Interfaces 10 1.3.2 CPC/CEAC Software Functional Desion Changes 13 1.3.2.1 Specification of CPC/CEAC Software Functional Change la 1.3.2.2 Transmittal of the Change 15 1.3.2.3 Revision of CPC/CEAC Functional Design Requirements 19 1.3.2.4 Devirion of Plant Data Base Listing 71 1.3.?.5 Recertification of CPC/CEAC FOPTRAN Simulation Program ?0 1.4 PHASE i DESIGN CHANGE nl!ALIFICATTON TESTfNG 21 2.0 IMPLEMENTATION, OCCUMENTATION AND TESTING OF SOFTWARE CHANGES 27 2.1 PURPOSE, SCOPE AND APPLICABILITY 27 2.1.] Puroose 27 2.1.2 Scoce 27 2.1.3 AEoTTcability 27

2.2 REFERENCES

FOR SECTION 2.0 29 2.3 SOFTWAPE CHANGE PROCEDURE 30 2.3.1 Origin of Software Changes 30 2.3.1.1 SCR Log 30 2.3.1.? Software Chance Pequest 31 2.3.2 Imolementation of Sof tware Chari.,ts 31 2.3.2.1 SCR Approval 31 2.3.2.2 SCR Review 31 2.3.2.3 SCR !mplementation 32 2.3.2.4 Review of SCR Implementation 36 2.3.2.5 Disk Generation 35 2.3.3 Ouality Assurance of Software Chances 37 2.4 FHASE I TESTINr. 40 ?.5 PHASE II TESTING 42 2.5.1 Cascriotion of Phasa 'T Testino d? 2.5.1.1 Input Sweap rest 43 2.5.1.2 Dynamic Sof tware Verification Test 44 l Pevision 03 Page a of 60 J

L. TAPI.E OF CONTcNT (Cont.i Section Title Paca No. 2.5.1.3 Live Inout Sinale Parameter Test 45 r 2.5.1.4 Modified Phase'TI Testing 47 l I 2.5.2 Phase if Test Case Selection 48 ?.5.2.1 Input Sweep Test Case Selectinn 48 2.5.2.2 Dynamic Software Verification Test Case L Selection 48 [ 2.5.?.3 Live Input Single Parameter Test Case Selection 50 2.5.3 Genara+ inn of Acceotance Cri+eria 50 1 2.5.3.1 Inout Sweep Acceptance criteria 50 2.5.3.2 Acceptance Criteria for Dynamic Software 2 Verification Test 53 2.5.3.3 Acceptance Criteria for Live Inout } Single Parameter Testing 54 2.6 PROCESS t0ISE EVALUAT!ON 54 l 3.0 GENERATION OF P70dECT SOFTWARE AND SOFTt/ AGE DES!GN i DOCl)MENTA TION j 3.1 PURPOSE, SCOPE AND APPLICABILITY 56 h 3.1.1 Purcose 56 3.1.2 Scoce 56 3.1.3 Acolicability 56 I 3.2 REFERENCE 5 FOR SECTION 3.0 57 ( 3.4 PP0 JECT DISK GENEoATION 60 -l 3.3 SOFTWARE DESIGN DOCUMENTATION GENERATION 58 LIST OF FIGURES 7u. * - ?Ull7%.'. L Ficure No. Title Page No. dr%.,.* ~ p.r .? e$ l' a 'id,d[g.a$ 8F. 2 1.1-1 CPC/CEAC Software Design QA Cocuments 22 [ 1.3-1 CPC/CEAC Software Functinnal Design ~.? f and Data Pase Modification Block Diaoram 73 d' % L, R 1.3-2 CPC/CEAC Software Chance Peauest Forn 74 .W 'a ! '. 7 *1 [ 1.3-3 Change Apolicability Form, CPC System 26 { 2.3-1 Desian/0A Activities 30 L. D '\\ "',I ..i a LIST OF TAPLES = ? if [' Table No. Title Paca %. Tg- .f g $ s4.... y 2.5-1 Dynamic Software Verificatinn Test Cases 41 G 4 F Y o Devision 03 Pace 5 o' 60 "E

l 1.0 SPECIFICATION OF SOFTWARE FUNCTIONAL DESIGti AND DATA BASE CHANGES 1.1 PURPOSE, SCOPE AND APPLICABILITY 1.1.1 Purpose The purpose of Section 1.0 is to present the relationships between various steps in the process of specifying modifications to the CPC/CEAC software functional design or data base constants. A series of steps resulting in modification of design documents prepared in accordance with Reference 1.2.1 are described to demonstrate that the process of specifying modifications is complete and is accomplished in a structured manner. As a result, the-integrity and consistency of the software functional design documents are maintained and generation of errors during the modification process is avoided. 1.1.2 Scope The scope of Section 1.0 covers requirements on the process of specification of a change to the CPC/CEAC sof tware functional design o and data base. The process covered in this section begins when the specific details of a change to the CPC/CEAC software functional design or to the data base have been established. The process O covered in this section ends when the follcwing documents have been revised in accordance with the procedures given in Reference 1.2.1. Pevision 03 Page 6 of 60

F 1 s g 1. Recorded calculations or other design analysis documents l} establishing 3pecifics of the CPC/CEAC functional design or i 3 f values of data base constants. Q m =sar 2. The CPC Functional Design Requirements; the CEAC Functional C l E 6 Design Requirements; and the CPC/CEAC Data Base Listing

  • 2 s

h 3. The CPC/CEAC FORTRAN Code Verification and Certification g t m

document, g

l-n 4 The Phase I Test Report 5. The Phase II Test Report D 4 {

  • (The CPC/CEAC Data Base Listing comprises the constants, g.

5 addressable or otherwise, required for the functional implementation 3 I ( of the CPC System. I'.s layout is based on the CPC/CEAC FORTRAN h k Simulation Code.) b se r ya 1.1.3 Applicability E 72fL These requirements are to be followed for all modifications to the T, "EE functicnal design and to the non-addressable constants, except the constants in the Reload Data Block, of the qualified CPC/CEAC 5 o b software and data bat,? constants for a given plant. Guidelires for -r-g = g the implementation of changes to the Reload Data Block constants are --g i n g defined in Reference 1.2.3. A prerequisite for use of these 7 n. I 1 m a Revision 03 Page 7 of 60 9 e r

requirements is that all applicable CPC/CEAC design documents have previously been completed in accordance with procedures given in Reference 1.2.1. and together reflect the complete OA'd status of software specification and implementation for a given plant. The applicable CPC/CEAC design quality assurance documentation for a given plant and the relationship between the various design documents are shown in Figure 1.1-1. .2 L l l Revision 03 Page 8 of 60

s

1.2 REFERENCES

FOR SECTION 1.0 1.2.1 Quality Assurance of Design Manual for C-E Nuclear Power Systems, i l 1.2.2 Core Protection Calculator Phase II Test Report, CEN-73(A)-P. 1.2.3 Reload Data Block Constant Installation Guidelines, CEN-323-P. Revisinn 03 Page 9 of 60

1.3 OESIGN INTERFACES AND MODIFICATION REQUIREMENTS The interfaces and activities requirad for modificatien o' CPC/CEAC design documents and Phase I and Phase it desion quali'ication tests are shown in Figure 1.3-1. During modification o' th* CPC/CFAC j f software design and/or data base cons' ants, thase documents are revised as required in accordance with crocedures given in Qeference 1.2.1 to accurately reflect the status of the modified desion. l j Section 1.3.1 describes the organization and interfaces between the various blocks shown in Figure 1.3-1. Section 1.3.2 describes the details of each block of Figure 1.3-1 that are associatad with speci+1 cation of the modification after the requirements of the modification have been established. 1 1.3.1 Design Interfacas The modification process is initiated when details of the modification have been established by the responsible C-E engineering group. For these requirements to be incorporited and referenced by the CPC/CEAC Functinnal Design Requirements or the Data Base Listing, they must be completed as recorded calculations or othar design docurants in accordance with Deferarca 1.2.1. After establishment of the details of tha modification, a Sof tware Changa Dequest (SCRi (Figure 1.3-?i shall be issued to the C F enginaarinq l qroup responsible for sof tware implementation. As evolained in I / Section 1.3.2.2, the SCP is desionad to allow software implementa-l tion to be planned or to proceed in parallel with ttle functinnal Q

R design OA process. Although individual SCO's are not raquired bv c the Reference 1.2.1 QA process, they are included herein 'or the following reasons: 6 6 B l 1. SCR's are referenced in revisinns to the CPC/CEAC Functional E [ Design Requirements to provide complementary information in the r form of traceability to the record of rev12 ions listed in these = M documents. The references to the SCR's are contained in the b reference sections of these documents and are of the form: E [ Revision i of this document implements the following Sof tvare 5 m I Change Requests: k. 1. m... J [ where i = the document revision number

k. 1. m = SCP numbers implemanted.

-6 h 2. Individual SCR's provide traceability. The originals are d retained in the design files of the software implementation group and copies are returned to the originating eroineering 2 group. E d = 3. Details of implementation of SCR requirerents including a g Change Applicability Form are transmitted back to the M originating design group so that can'irmation that tha SCP was = m h. correctly understood is provided. A copy of the SCR forat used m [ for CPC/CEAC so'tware modifications is shown in Figura 1,3-? m F mm and the Changa Applicability Form is shrwn in Figura 1.3 3. 1 - Es m 3 = = Revision 03 Page 11 of 60 M

-e 2 Upon completter of detailed modification requirements in accordance 1 m --um with Reference 1.2.1, these requirements are referenced by the h associated revision of the CPC/CEAC Functional Dasign Requirements f and/or Data Base Listing documents. The revisions of these f w documents are discussed in Sections 1.3.2 3 and 1.3.2.4 E E respectively. The CPC/CEAC Functional Design Requirements and Data 3 1 M Base Listing documents are revised in accordance with Reference f{ 1.2.1 and are transmitted to the software implementation group. i i h o For those modifications which impact the CPC/CEAC FORTRAN code, the f CPC/CEAC FORTRAN code certification document is revised. All g revisions to the FORTRAN code are do'e in accordance with the d I require' rents of Reference 1.2.1. The code certification document is k referenced to the appropriate revision of the CPC/CEAC Functional y y Design Requirements. Revisions to values of existing data constants f in the Data Base Listing do not require alteration of the FORTRAN L h code, since the values of data constants are not specified within -{ the code, but are inputs to the FORTRAN code from a plant specific M h data base file defined in the Data Dase Listing. ".E = ? A _R For those modifications which impact the performance of the -q -g 7 algorithms, the CPC/CEAC FORTRAN code is used to generate espected Q results for Phase ! and Phase !! qualification tests using the E j appitcable certified data ba'.e file. The result *, of the FORTPAN b cases are used in the revisions of Phase ! and Phase !! Test Reports. These Test Reports will referance the appropriate revision of the CPC/CEAC FORTRAN code and the applicable data base file. g Pevision 03 Page 12 of 60 M E d" m =

As shown in Figure 1.3-1, the Software Change Request (Figure 1.3-2), the CPC/CEAC Functional Design Requirements, the CPC/CEAC Data Base Listing documents, and the CPC/CEAC FORTRAN code results all interface with the implementation portion of the software modification process. The implementation of software modifications is discussed in Section 2.0. 1.3.C CPC/CEAC Software Functional Design Changes This section describes the actions to be taken by the CPC/CEAC functional design group to specify changes to the CPC/CEAC n software functional design and data base. The sequence of events is described from determination of the requirement for a change to completion of QA documentation of a revision to the CPC/CEAC functional design or data base. The following major steps in the design change process are detailed within this section: l 1) Specification and transmittal or a functional change and/or a data base change 2) Revision of Functional Design Requirements 3) Revision of Data Base Listing l 4) Recertification of CPC/CEAC FORTRAtl Simulation Code I Revision 03 Page IJ of 60

5) Change Qualificatinn 1.3.2.1 Specification of CPC/CEAC Software Functional Change f When a CPC/CEAC software functional design change has been identified and fully defined, it shall be transmitted to a CPC/CEAC Design Engineer responsible for execution of tN CPC/CEAC functional design change procedure. If the change does not af'ect CPC/CEAC FORTRAN Simulation Code, the functional design change shall be sent directly to the software implementation group according to Section 1.3.2.2. An example of a functional design change not requiring a FORTRAN code change is addition or deletion of a point 10 assignment to a CPC calculated variable for accessing the value of the variable at the CPC operator's module. If the change does affect aspects of the CPC System simulated in the FORTRAN code, the change will be implemented in the CEC /CEAC FORTRAN O mulation Code according to Section 1.3.2.5. 4 Conct.crently with the code certification process, individual modifications may be implemented in the CPC/CEAC FORTRAN Simulation Code. Appropriate test cases shall be run to assure that the revised simulation code li error free and that the revised algorithms produce the desired results before the change is transmitted to the software implementation group. The test cases will normally be Phase !! static or dynamic test cases, Poference 1.2.2, selected to l exercise the modified portions of the FORTRAN code. Revision 03 Page 14 of (30

E As no*ed in Section 1.3.1, the Functional Dasian Raquiraments ara Q based upon recorded calculations or other design documants (See Figure 1.1-1). The calculations and dccuments referenced by the --7 Functional Design Requirements employ, if recuired, standard C-E design codes to determine the adequacy of the design modification with respect to those codes. The recorded calculations, the Functional Design Requirements and the FORTDAN code certification -b Y document are all Quality Records as definad in Reference 1.2.1, and N are available for audit. Q J -= 1.3.2.2 Transmittal of tha Change T -m The medium for transmittal of individual software functional design i changas or data base changes from the sof tware 'unctinnal qroup to the software implefaentation group is the Software Change Dequest 5a (SCR) form shown as Figure 1.3-2. The SCR supolaments the 'emal quality assured Functional resign Daouirements and Data Base Listing documents, ft is a means of providing orderly communication batwaen groups with design soecificatien rasponsibilitv and groups wi+h _] design implementation resconsibility. Quality assurance of a 3 software design change is astablished by revision nf the CPC (CEAC) Functional Dasign Recuirements and/or the CPC/CEAC Data Aasa Listinc documents. Revisions of the CPC (CEACi Functional nasion Requirements will have references to applicable SCDs as i supolement _= to the ecord of revisions required 'or these documents. J 4$ mu Revision 03 Page 15 of 60 -q a

Completed SCR forms must be approved by both the functional design grcup and the software implerrentation group. At the too o' the form are blanks for enterina the following information: 1) SCR #: a unique sequence number 'or the SCR obtained by entering a line in the SCR Log (see Section 2.3.1.1). 2) Date: date on which the SCR is filled out. 3) Plant (s): plant or plants for which the SCR applies. I j The remainder of the SCR consists of six parts. Guidelines for l completion of each part are provided below: i f. Originator / Supervisor: Sectinn and name of the criginator of the SCR. II.

References:

These are documents civing the basis for the change or are other SCPs affected by this SCP. l Ilf. Summary of Chance: If the change is mince, it may be described in the space provided. For more extensive changas a descriptive phrase is enterad in the space prnvided, and a detailed description of the change is provided en attached pages. The change description should adhare to the following guidelines for each plant affected by the change: Revision 03 Paqe 16 of 60

/

1) All parameters are referred to by their functional description 0.4.* variable names. 4 21 Arithmetic operations are described in standard mathematical notation. ~ 31 Logical operations, branching, and loops are described in concise prose using relational operators such as >, s, /, etc. E' 4) If necessary to avoid ambiguity in location of inserted or i' deleted operations, copies of ' low charts from the current revision of the plant software specifications should be, annotated ard included in the chance description. Copies of the old and new CPC FORTRAN Simulation coding may also be I' attached to avoid ambiguity. ('~, 5) Constants and variables deleted from a given procram hy the j.. change must be identified. 6) New constants shall be identified tocether with their Y' attributes such as integer or real, addressable Type I or Type l II, or Reload Data Block. 7) Any existing constants that have changed Status between any of P " protected", " addressable Type I", " addressable Type II" or '.,Q. # ' r ~~. ' t y " Reload Data 91ock" shall be identified. - ' 4. ~..[. ;h 7 Okh 8) Changes in the values of existing constan*s shall be stated. Range (s) for new addressable and Reload Data Plock constants g,, 3-shall be defined. 9) Determine need for "Other Reviewer" and specify the group to p.',. ?.l...j ., 9 'j. - perform this reviaw. . M l.' k,. (- r Q...: b.. 1. . ;r-..., g 6.. a.' 3 Revision 03 Page 17 of 60 .:-h i > l e, ;.9,.< } V,: .>u %_.,

IV. Program (s) Affected: List of CPC S.vstem programs affected by this SCR. V. Approvals:

1) The cognizant functional design supervisor or designee must review and approve the SCR. Upon approval, the SCR shall be transmitted to the software implementation group and to other design groups as appropriate.

2) Upon receipt of the SCR, the software implementation supervisor or designee must indicate the acceptance of the SCR by signing the indicated blank. 31 The software implementation engineer implementing the chance annotates the SCR to indicate any clarification obtained verbally and signs the " Implemented by" line when implementation o' the SCR has been completed. 4) Copies of the annotated SCR, revised flow charts, Change Applicability Form, and details of the implementation necessary for clarification are returned to the functional design group and other appropriate design groups for review of the implamentation to verify correct interpretation of the SCR and signature of the "Impl. Reviewed by" and "Other Reviewer (as l aporopriate)" line is obtained. Revision 03 Page 18 of 60

VI. Design Documents Affected: The SCR originator must determine whether the change described in the SCR requires revision of each item listed for each plant affected by the change. When _ revision of a given document is completed the person responsible for completion of the respective document enters the date of completion and the "Rev" number of the revised document in the appropriate columns on the original SCR. 1.3.2.3 Revision of CPC/CEAC Functional Design Requirements As stated above, the SCR is not a formal quality assured document. The SCR allows software implementation design to be planned or to begin as soon as the details of a required functional design change are known. In this way revision and review of quality assured functional design documentation can proceed in parallel with software design activities that require substantial lead time. Revisions to the CPC (CEAC) Functional Design Requirements required ! by an SCR shall be incorporated in accordance with Reference 1.2.1. Upon final approval of the revised CPC (CEAC) Functional Design Requirements, lines VI A and/or VI B (CPC Functional Design Requirements and CEAC Functional Design Requirements) of all SCRs encompassed by the revision shall be completed. In addition, for all SCRs encompassed by the revision, any recorded calculation revisions or new recorded calculations referenced by the revision to Revision 03 Page 19 of 60

the functional description (s) shall be listed on line VI F (Recorded Calculations) and the revision number and date of completion of those calculations shall be filled in. The approved revisions of the CPC (CEAC) Functional Design Requirements shall be transmitted to the software implementation group to provice quality assured input for the revision of the CPC/CEAC software specifications. 1.3.2.4 Revision of Plant Data Base Listing Revisions to a Plant Data Base Listing shall be incorporated in accordance with Reference 1.2.1. Upon final approval of the revised Plant Data Base Listing, line VI C (Plant Data Base Listing) of all SCRs encompassed by the revision shall be completed. In addition, for all SCRs encompassed by the revision, any recorded calculation revisions or new recorded calculations referencad by.the revision to the data base shall be listed on line VI F (Recorded Calculationsl and the revision number and~date of completion of those calculations shall be filled in. The approved revision of the Plant Data Base Listing shall be transmitted to the so'tware implementation group as quality assured input to the revision of the CPC/CEAC software specifications. The Plant Data Base Listing shall also define the name of the applicable quality assured CPC/CEAC FORTRAN Simulation data base file. Revision 03 Page 20 of 60

^ i 1.3.2.5 Recertification of CPC/CEAC FORTRAN Simulation Program Verification, or " certification" of the CPC/CEAC FORTRAN Simulation code is done in'accordance with Ref. 1.2.1, which includes requirements on tests for correctness, test bases, test results, supportive data, printouts, hand calculations, and listings. The CPC/CEAC FORTRAN code verification process ensures that the functional design as specified in the CPC (CEAC) Functional Design Requirements has been correctly implemented in the FORTRAN code. When recertification has been completed, the "Rev" number of the new certified version of the code is antered in the appropriate column of line VI D in SCRs encompassed by the revision. 1.4 PHASE I DESIGN CHANGE QUALIFICATION TESTING Phase I test cases to be run shall be determined by the software l implementation group and a definition of the test cases shall be provided to the functional design group. The functional design group shall execute these test cases using the CPC/CEAC FORTRAN l Simulation Code and return the results to the implementation group for analysis and inco'rporation into the Phase I Test documentation. Further discussion on Phase I testing is provided in Section 2.0. i Revision 03 Page 21 of 60

FIGURE 1.1-1 CPC SOFTWARE DESIGN QA DOCUMENTS STATIC POWER UPDATE DNBR DISTRIBUTION CONSTANTS CONSTANTS CONSTANTS i FLOW CEAC l CALCULATIONS CONSTANTS CONSTANTS 1 o ,re,,ry FUNCTIONAL PLANT CPC/CEAC DESIGN

DATA BASE REOUIREMENTS DOCUMENT

) CPC FUNCTIONAL DESIGN CPC/CEAC SOFTWARE IMPLEMENTATION' FORTRAN I SIMULATION 9 SOFTWARE SOFTWARE DESIGN DESIGN SPECS DATA BASE DOCUMENT l <r PHASE I PHASE I TEST SUPPORT g-- CALCULATIONS CALCULATIONS /% 1f 'P CALCULATIONS PHASE I PHASE II '"~ TEST REPORT ,e P PHASE II PHASE II TEST SUPPORT TEST REPORT CALCULATIONS TEST & CODE CERTIFICATION Revision 03 Page 22 of 60

DETAILED REQUIREMENTS FOR MODIFICATION TO CPC/CEAC SOFTWARE FUNCTIONAL DESIGN OR DATA BASE ARE ESTABLISHED 1r ISSUE SOFTWARE MODIFY CPC/CEAC FUNCTIONAL CHANGE REQUEST (SCR) DESIGN REQUIREMENTS AND/OR DATA BASE LISTING d if AS REQUIRED, REVISE AND RE-CERTIFY CPC/CEAC FORTRAN CODE SPECIFICATION y y 3r (SECTION 1.0) AS REQUIRED, RUN AS REQUIRED, RUN PHASE I TESTS PHASE II TESTS AND REVISE AND REVISE TEST

SUMMARY

TEST

SUMMARY

N IMPLEMENTATION (SECTION 2.0) y n IMPLEMENTATION OF SOFTWARE MODIFICATION 1. CPC/CEAC SOFTWARE. SPECIFICATION 2. CPC/CEAC SOFTWARE DESIGil DATA BASE 3. CPC/CEAC ASSEMBLY SOURCE FILE AND LISTING 4 CPC/CEAC REFERENCE AND MASTER TEST DISKS i l l FIGURE 1.3-1 CPC/CEAC SOFTWARE FUNCTIONAL DESIGN AND DATA BASE MODIFICATION BLOCK DIAGRAM Revision 03 Page 23 of 60

SHEET OF SCRa: l Date: Plant (s): CPC SOFTWARE CHANGE REQUFST I. Originator / Supervisor: II.

References:

III. Summary of Change: (use additional sheets if necessary) IV. Program (s) Affected: ~V. Functional Design Group Approval Implementation Group Approval Implemented by Implementation Reviewed by Other Reviewer (as appropriate). Figure 1.3-2 Revision 03 Page 74 of 60

SHEET O F__ _, SCR*: Date: VI. FUNCTIONAL DESIGN DOCUMENTS AFFECTED Plant: Rev Yes No Date Completed A CPC Functional Design Requirements B CEAC-Functional Design Requirements C Plant Data Base Liscing D FORTRAN Simulation Code E Phase II Test Report F Recorded Calculations: d l i Revision 03 Page 25 of 60

E FIGURE 1.3-3 Sheet of CHANGE APPLICABILITY FORp SCR#: CPC SYSTEM Date: Plant: Initials: Change Completion Date and Initials Applicable Software Item Listing Source Object Specification Revision 03 Page 26 of 60

--, e e

,c ,,.,i y. -.m..-, ,--c--w-m-- = g-w, - - - -- -gp

2.0 IMPLEMENTATION, DOCUMENTATION AND TESTING OF SOFTWARE CHANGES 2.1-PURPOSE, SCOPE AND APPLICABILITY 2.1.1 Purpose The purpose of this section is to specify the steps required to test and document a design modification to the CPC/CEAC system software. Adherence to this procedure is intended to avoid the introduction of errors during the revision of a quality assured software system and its related documentation. 2.1.2 Scope This section covers the implementation of a software design change. The specific activities include modification of the system sof tware specifications including program equations, data base, flowcharts, the Phase I Test Report, and the Phase II Test Report. Requirements are included for documentation and testing of sof tvare changes. 2.1.3 App 1fcability Application of the procedures covered in this section is mandatory for modifications to CPC/CEAC software systems, with the exception of changes of values of Reload Data Block.ind addressable constants, subsequent to the initial design qualification of the software Revision 03 Page 27 of 60

system. A prerequisite for application of this procedure is that all applicable system design documents have been completed in accordance with Reference 2.2.1. f t-l l I l i l-r L Pevision 03 Page 28 of 60 f

2.2 REFERENCES

FOR SECTION 2.0 2.2.1 Quality Assurance of Design Manual for C-E Nuclear Power Systems. 2.2.2 Core Protection Calculator System Phase I Design-Qualification Test Report,CEN-72(A)-P, October,1977. 2.2.3 Core Protection Calculator Single Channel Qualification Test Report, ~ CEN-71(A)-P, Supplement 1-P, September, 1978. 2.2.4 Core Protection Calculator Software Change Procedure Supplement CEN-39(A)-P, Supplement 1-P. 2.2.5 CPC Protection Algorithm Software Change Procedure Supplement, CEN-254(V)-P. Revision 03 Page 29 of 60

2.3 SOFTWARE CHANGE PROCEDURE 2.3.1 Origin of Software Chances 2.3.1.1 SCR Log A software change, of algorithm or data base, originates when either the responsible functional design group or software implementation group identifies the need for a software change and obtains a unioue software change request (SCR) n'mber by entering a line in the SCR Log. The SCR Log is a formal notebook containing for each SCR: 1) The change number assigned to the SCR. SCR numbers shall be assigned in increasing consecutive numerical order. 21 The date on which the SC9 is entered.in the log. 3) The originator of the SCR. di The sub.iect of the SCR. A descriptive phrase de#ining the change to be requested. 5) The initials of the implementer of the SCR and the date. () completed, i s Revision 03 Page 30 of 60

2.3.1.2 Software Change Request i After obtaining an SCR number, the cognizant engineer in the originating group generates a Software Change Request, the contonts of which are discussed in Section 1.3.2.2 of this document. 2.3.2 Implementation of Software Changes 2.3.2.1 SCR Approval All SCRs will be approved by the supervisor, or designee, responsible for the software implementation to signify the acceptability of the requested changes. 2.3.2.2~ SCR Review A approved SCR will be forwarded to a system cognizant engineer who evaluates the change for overall system impact and reports confirmed or potential problems to the responsible supervisor who will seek their resolution. If the cognizant engineer receives additional information vet-ly, it will be recorded on the SCR and initialed by the cognizant engineer. The verbal infonnation w'll be highlighted by underlining or bracketing to facilitate validation by the originating group when the annotated SCR is returned. Revision 03 Page 31 of 60

2.3.2.3 SCRImplementation Implementation is defined as the translation of the system functional requirements into modules of machine executabla code, and the integration of these modules into a real-time software system. The implementer will prepare, design, code, and implement the Software Change Request using the following procedures, detailed in References 2.2.4 or 2.2.5. The implementer will pr? pare the software change package by filling out and attaching to the SCR a Change Applicability form (Figure 1.2-3) for each plant to which the SCR pertains. The engineer must list those items which are affected by the SCR on the Change Applicability form and must date and initial each item when the required changes are completed. If the implementer determines that additional information is required, he will. contact the originator to obtain the required clarification. All pertinent information received verbally.will be recorded on the SCR and initialed by the engineer. The software change package will be maintained by the implementer until the change has been implemented and tested. 'he package will then be returned to the originating group for review. The implemen-tation group will file the package in the CPC design file. Revision 03 Page 37 of 60

After preparing the software change package, the engineer will design and implement the required change as follows: 1) The iglementation will be based on most recent revision of the affected calculation descriptions, flowcharts, cross reference lists, input / output lists, variable lists, and constant lists of the System Software Specification. C 2) The required coding changes will be marked on the most recent working copy of the assembly listings. When a new listing is created, the previous version of the listing will be marked " superseded." 3) The Phase I Test Cases will be reevaluated as detailed in Section 2.4 of this document. 4) If the change affects scsled-fixed-point coding, the appropriate scaling recorded calculations will be revised accordingly. The software change will then be incorporated in a specification revision. The revised software design will then be independently reviewed in accordance with Reference 2.2.1. Revision 03 Page 33 of 60

All CPC/CEAC source files affected by the change will be updated.In the course of implementing the changes, the following documentation will be performed: 1) A revision to CPC software consists of one er more SCRs. In the initial updating of a source file during a revision, the revision number of the source file is incremented by 1.00 and the decimal part of the number is reset to.00. In the implementation of subsequent SCR's within this revision, which result in another updating of this source file, the revision number of the source file is incremented by 0.01. 2) An "SCR Implementation Record" line will be inserted into the source file. This line is a comment of the form:

  • REV n.nn, SCRs:

i, j, k,... where: n.nn is the new revision number i, j, k are the SCR numbers implemented in this revision. These lines will never be removed from the file and will thus provide a running account of the SCRs implemented in a particular program. The updated CPC/CEAC source files are then assembled to create object modules. Revision 03 Page 34 of 60

To complete a so#tware change package and the implemen+ation of an SCR, the implementer will fully debug the generated ob.iect module (si. If a program error is detected during debug it will be corrected and all affected documentation, including the software change package, will be mcdified as recuired. The..rtision level, however, will not be incremented for changes to correct errors in the SCR implementation uncovered during debuo testing. When the ob.iect module has been fully debuoged, the imolarenter will complete the change package by attaching the Source Updater nutouts, filing the test cases in the CPC design file, #illing in the applicable columns in the Charge A olicability Form and initialing D and dating the SCR. The implementer will then return the change package to the coanizant engineer and will initial and date the SCP Log. The cognizant engineer will check the change package for completeness and file the completed package in the system desion file. 2.3.2.4 Res ew of SCR Imolementation An annotated cony of all SCRs will be returned to the cricinator with copias of the marked up calculation descriptions and ' low charts. The oriqinator will ther raview the implementation and sign off the SCR to ccmplete the design chance package. Revision 03 Page 35 of 60

2.3.2.5 Disk Generation The implementer will generate new reference and test disks using the following procedure the details of which are contained in Re'erence 2.2.4 To generate a new reference disk, load modules will be created from the individual program and constant files object code. Each sector of a new disk will be initialized to all zeroes before any programs are written to the disk. A disk may be generated ent: rely from revised object code, copied entirely from the reference disk or s copied from the reference disk with a revised obiect utdate. I Phase I and Phase II testing shall be performed nn the new disk when required in accordance with Sections 2.4 and 2.5 of this document. A disk which has satisfactorily undergone all testing required by the above sections shall become the new reference disk for the software system. Once a reference disk has been e-tablished for the so#tware system a master test disk may be generated. This is accomplished bv reassembling all source files for the system to generate new obiect modules. An entire system load module will be generated from these object modules and written to disk. Revision 03 Page 36 of 60

When tha master test disk has been cenerated, it will be compared to the re#erence disk. I# dif#erences are encountered, it will be determined whether the error is in the reference disk (f.e. an error missed by required testing) or the master rest disk. The error will be corrected and the faulty partion of the disk will be regenerated in accordance with all applicable procedures for reference or test (isk generation and testing. If no errors are encountered, the listings generated from the assembly of the source files will become the final listings for the current revision of the software system. t Disks for shipment to customer sites for on-line operation will be duplicated from the system reference disk, maintained by the software implementation group. The test disks will be similarly generated by duplicatino the master test disk cen* rated above. The master test disk will be maintained by the software implementation l group. P.3.3 Ouality Assurance of Software Chances The revised system Functional Desion Pequirements and/or Data Pase Listing are the design input to the CPC/CEAC software modifications. Any revisions to CPC or CEAC software are documented by revising the system software specifications. Quality assurance of the #inal software implementation is established by independent review of the Revision 03 Pace 37 of 60

design in accordance with Reference 2.2.1 (QADM) and by Phase I and Phase II design qualification testing described in Sections 2.4 and 2.5 respectively. A flow chart of design and QA activities is shown in Figure 2.3-1. 1 Revision 03 Page 38 of 60

s l! m As.4.i 1 j ACty mt scR NW e D. D T D TW 3 0 100 M = l 3cm tac DETTifE3 RMUDC C?IulcE l 8CE l gg*g;y EEYTDi A!L TCC3GrTATTTW, DEYtirE Att IT

  • RmW c6. ;ElTM Att RM73D pgyg SOFTWLAE -

stTTcitT3G DATA /TNFCSMATTOW. l CMLEGE SETIBI3 CHA3 ICES PRUIRED TO SAEE TEST 3r n'"m'2 l SAs1 Sof%ARE T w DESI:N c! guess Itstt:t2 AC toc 3Cf!!D Or ALL m CMacg 3EAttID Doc 3Cr!ATICE a t CA,c.u:, ag .tuttstFenATIDE or cumss crr0 Tm 3AsE A. -E=== T nEr sID reencuAL

cm:ct:r:

mIvIrv Or It31:a tocur:Anor Pts aggr2RD CITS ret M RETIDF gyygggggg ggcy matt tasE Doceert T T!E 30rNutE c1Duur:E 3 IMP:23Cr:ED Ir Somer FOPmt U AggDStf LIITDG AND OW1E"! CSI 3 N0r!DD DE3Ian Z37 Tm scriunst c!DLicE IS DI5tDcED RESC23 + 1 gc3 tog STER cf7 Scit 100 I3r3T. FTIE AIL i 3Eav 3 D tt31:28 Doco mITATIDE D BETWW N I QL1ECT CEEE matin rt E est Fca REnDr to CENIEATES A RETI3ED MET D DISK e 190cIDtRE T PHASE I I FDircpM AIL RMU3D FIIAE2 I TIT 73 TEST M i 7RLst I TEST i Ac:EP:AscE G I ERTA , y DREA PIELEE I TIET 30c3erf 7MAEE I TEIT RESUC3 BEstE:3 T 3133308N txttrDtDDrr RITIDr W PEASE I TIET RETIDt RESEr5 T FRASE II PERrcitM AIL EttU3ED F9L51 II T!3TS TEST ?! toc:Ut1 FRASE II TZ3: AccEFTAse:E GIIIIIA h ( T!st Esc l cc3er! P5nst II TEST R15 =3 T mcEFutur I tscE75c:Z:rt E7II3r cr PfDLEE II TIIT EEYID' I REBUCI t D r = ATE ms En T:CirE 3ACKt? FT33 3 A SEPARATE / rng= toexxD ITURAct ARTA T l ASEDR3 l AssDs3 BACEP T Manes cupATE.TE TEST DisEs new 1AccP ymocID3t1 AE3DSLT AarD cpERATE TEE FtELD DISES FMM TEE MAST U D!$ES FDtzcoIc Tzr; FDrestM : meat::w 3Y to AT::s ims TO VDIFT RE7tIO.ATD Di$ES y SRtF THE FIE!.D 14AD DISES AND f tE13 PER1001C TEXT 3!SES' TO Tite SITI FIGt9E N0. 2.3 1 t2:f3 /Q4 Acf 6 Revision 03 Page 39 of 60 i-

2.4 PHASE I TESTING Phase I testing will be performed to verify the implementation of modifications to the CPC/CEAC Software. Phase I testing is ) I performed on relatively small, single-entry / single-exit secments of code called modules (or SVCs in the CPC/CEAC Executive Programs). Any modifications to a program's code will require the regeneration of the entire program. All of the modules or SVCs that were modified will undergo a complete rerun of Phase I testing. Test case inputs will undergo reevaluation such that each possible functional branch and each related constant in the affected modules or SVCs is exercised. Program. wide test cases will then be run to assure correct generation of the program. Any modifications to a program data base, as defined in Section 2.1.3, will require regeneration of the program constants. All of the modules or SVCs of a program which access the affected constants will undergo a complete rerun of Phase I testing. The program containing these modules or SVCs will then be Phase I tested with the program wide test case inputs. All Phase I test documentation will be revised. This includes the test case selection calculations and the Phase i Test Deport. l Pevision 03 Dage 40 of 60 l

All Phase I Test documentation will be quality assured including independent review in accordance with Reference 2.2.1. Details of Phase I testing are provided in a Phase I Test Procedure. Revision 03 Page 41 of 60

2.5 PHASE II TESTING 2.5.1 Description of Phase II Testino Phase II testing consists of the following tests: (1) Input Sweep Test, (2) Dynamic Software Verification Test, and (3) Live Input Single Parameter Test. These tests are performed on a single channel CPC/CEAC system with integrated software that has undergone successful Phase I testing. The single channel CPC/CEAC system is described in Reference 2.2.3. The objectives of Phase II testing are to: 1. verify that the CPC and CEAC software modifications have been properly integrated with the CPC and CEAC software and the system hardware, and 2. confirm that the static and dynamic operation of the integrated system as modified is consistent with that predicted by design analyses. The Phase II testing uses the CPC/CEAC FORTRAN simulation code as a basis for comparison. The results of Phase II testing including s I test case selection and acceptance criteria are included in the Phase II Test Report, Revision 03 Page 42 of 60

?. 5.1.1 Input Sweep Test The Input Sweep Test is a real-time exercise of the CPC (CEACI application software and executive software with steady-state CPC (CEAC) input values read from a storage device. Separate Input Sweep Tests will be performed for the CPC and the CEAC software, each with the appropriate inputs. The Input Sweep Test has the following obiectives: (1) To determine the processing uncertainties of the CPC (CEACI algorithms as used in the CPC/CEAC system hardware that are inherent in the CPC (CEAC) design. Processing uncertainties are defi.ned as those resulting frem differences between the machine precisions of the CPC system and the more accurate CPC (CEAC) FORTRAN Simulation. The CPC processing uncertainties will be factored into acceptance criteria for the Dynamic Software Verification Test, and the Live Inout Single Parameter Test. The CEAC processing uncertainties will not be used in further phases of software testing. (2) To verify the ability of the CPC (CEAC) algorithms used in the l system 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. i t Revision 03 Page 43 of 60

(3) To complement Phase I module testing by identifying any abnormalities in the CPC (CEAC) algorithms used in the system hardware which were not uncovered previously. This test is performed using the CPC (CEAC) software overlayed with Input Sweep software, using unused portions of memory and a portion of the Executive Initialization Task for the overlay; the CPC (CEAC) application programs to be tested remain unaltered. The Input Sweep software allows test case input values to be read from a storage device. A large number of static test cases are selected which cover the range of CPC (CEAC) operation, including the upper and lower limits of all CPC (CEAC) inputs. These test cases are allowed to initialize, after which calculated parameter values are compared off-line with expected values generated with the CPC/CEAC FORTRAN I code. 2.5.1.2 Dynamic Software Verification Test (DSVT) The Dynamic Software 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 DSVT has the following objectives: Revision 03 Page 44 of 60

1. To verify that the dynamic response of the integrated CPC software is consistent with that predicted by desian analyses, and 2. To supplement design documentation cuality assurance, Phase I-module tests, and Input Sweep tests in assuring correct implementation of software modi #ications. The Dynamic Software Verification Test (DSVT) is similar to the CPC Input SweeD Test in that special software is overlayed on portions of the executive software ano on unused portions of memory, leavino the CPC application programs unaltered. As in the Input Sweep test, CPC input values are read from a storage device. However, while the' Input Sweep test terminates the execution of each test case after it has initialized to a steady-state condition, the DSVT, after initialization, uses time-variant test case input values to exercise " dynamic" portions (recursive or time-derivative equations) o# the p' i 'I f'$ CPC software. 2.5.1.3 Live Inout Sinole-Pararreter (LISP) Test AtM The LISP rest is a real-time exercise of the CPC/CEAC application N ) and executive software, with transient CPC/CEAC input values generated from an external source and read through the CPC/CEAC input hardware. The objectives cf this test are: Revision 03 Page 45 of 60

1. To verify that the dynamic response of the integrated CPC/CEAC software.and hardware is consistent with that predicted by design analyses. l 2. To supplement design documentation quality assurance, Phase I l module tests, Input Sweep tests, and OSVT testing in assuring correct implementation of software modifications. 3. Evaluate the integrated hardware / software system during operational modes approximating plant conditions. Unlike Input Sweep and DSVT tests, the LISP test employs no special test software for generating test case input in the CPC/CEAC system. Dynamic test case inputs are generated by external test equipment to produce " live" analog ard digital signals that are input t.- the CoC/CEAC input ~processino hardware. Since multi-variable transients are already performed in the DSVT test, each LISP test case varies only one input parameter, holding other inputs at constant values. Limiting live input transients to single variables is also based upon minimizing test uncertainties due to input signal generation and transmission, enabling a higher degree of precision in test acceptance criteria. All dynamic portions of the CPC/CEAC algorithms will be exercised with LISP tests. Revision 03 Fage 46 of 60

2.5.1.4 Modified Phase II Testing s I l I I i l l 1 1 Revision 03 Page 47 of 60 i i -~-~*- ,c q y -e a -m. --m,ym-- --w-..- y-- m w

*-g----,---w-w-.wy-w

.& ea g y ,w- ,p---- g --wa-s-m v '7

2.5.2 Phase II Test Case Selection 2.5.2.1 Input Sweep Test Case Selection The objective of the Input Sweep Test case selection is to define a l minimum of 500 cases which cover the region of CPC' operation, \\ l including upper and lower limits on CPC inputs. The selection is designed to ensure a high confidence level in the determination of processor uncertainties, in the detection of anomalies, and in the initialization capability. The spectrum of selected cases must therefore be based upon a sufficiently wide spectrum of cases covering the range of selected addressable constants and of CPC inputs, allowing for mechanistic constraints associated with plant operation (i.e., the 3 ex-core detector inputs must be a matched set, hot leg temperature must be greater than cold leg temperature, etc). Within these constraints, test case selection may be random or systematic. A typical test case selection process is described in Section 4.2 of Reference 2.2.2. 2.5.2.2 Dynamic Software Verification Test Case Selection The objective of the selection process is to employ cases that adequately exercise dynamic portions of the application software, with emphasis on thorcughly testing those portions of software that have been modified. Revision 03 Pcge 48 of 60

Table 2.5-1. lists the test cases which simulati all the CPC System design basis events and the CPC System limiting operating transient l events. The DSVT test cases for a given software modification will, as a minimum, consist of cases 5, 11, 12, 16 and 17 from Table 2.5-1. Lepending on the nature and complexity of the modification, additional cases from Table 2.5-1 will be selected as necessary to exercise the affected portions of the CPC software. 2.5.2.3 Live Input Single-Parameter Test Case Selection The objective of LISP test case selection is to demonstrate that the integrated CPC/CEAC hardware / software system functions as designed in response to externally-generated transient input signals in a real time environment. Test cases will be variations of single variables encompassing, as a minimum, cases 17 through 21 of Table 2.5-1. In addition, major aspects.of the operator's module operation, particularly those accessing portions of modified applications software, will be exercised. 2.5.3 Generation of Acceptance Criteria 2.5.3.1 Input Sweep Accaptance Criteria As stated in Section 2.5.1.1, the Input Sweep Test has three ob.iectives: Revision 03 Page 49 of 60 (

~ Table 2.5-1 1 Dynamic Software Verification Test Cases Revision 03 Page 50 of 60

_ _.. ~ _ -(1) Determination of processing uncertainties. ~ (2) Verification of initialization. (3) Identification of abnormalities. l i 4 Pevision 03 Page 51 of 60

  • T ~ ~'.: 'L -. *. - -- - -- - - - -.

I l I 4 i .i 4 i r i 4 4 e t J l } t i Revision 02 Page 52 of 60

l l 2.5.3.2 Acceptance Criteria for Dynamic Software Verification Test i j Revision 03 Page 53 of 60 J ..~

m -- 2.5.3.3 Acceptance Criteria for Live Input Single Parameter Testing l 2.6 PROCESS NOISE EVALUATION Software changes will be evaluated for their potential to signifi-cantly alter (with respect to the previously qualified software) the CPC/CEAC System response to plant process noise. The evaluation will be performed during the functional development of the software modification, and will be supplemented by observations of system behavior during Phase II testing. Particular attention during such evaluations will be given to changes in data or equations involving (1) recursive or time derivative calculations, (2) deadbands, nodes, range limits, or discontinuities, and (3) the static sensitivity of DNBR, LPD, or quality margin with respect to process inputs. If the evaluation indicates that the potential for significant alteration of the noise response exists, the modified CPC/CEAC software will be evaluated by testing to verify that the altered noise response is acceptable. In the event that roise testing is necessary, the tests will be performed by adding noise signals to the neminal(static or dynamic) Revisinn 03 Page 54 of 60

values.of selected simulated process inputs to the Single Channel System. These inputs include pump speeds, temperatures, pressure, and excore detector signals. To the extent practical, the noise l signals that are used'must be the best available representation of ~ l l actual plant noise, with the preferred source being FM tape i recordings of in-plant noise on CPC/CEAC process inputs. Recorded noise-from in-plant and CPC/CEAC process inputs may be supplemented with synthesized noise (having frequency and amplitude characteristics similar to actual plant noise), or recorded noise from non-CPC/CEAC plants. l The noise generation capability of the Sir.gle Channel Test Facility includes a 16-channel FM tape recorder and appropriate amplification equipment to enable the CPC/CEAC single channel system to use recorded in-plant noise as part of the noise evaluation. Random l noise synthesis capability will be available with a broadband noise generator capable of well defined frequency spectra, frequency cutoffs, and power output. In addition, systematic noise synthesis capability will be available with two sweep generators that cover a 4 broad range of frequencies and waveforms. l Acceptance of the noise response test results is based upon (1) j determination that any non-conservative (relative to the noise-free condition) DNBR or LPD values are accomodated by measurement uncertainty allowances in the CPC System and (2) determination that I the plant availability will not be unacceptably impacted by the altered noise response. Revision 03 Page 55 of 60

3.0 GENERATION OF PROJECT SOFTWARE AND SOFTWARE DESIGN DOCUMENTATION 3.1 PURPOSE, SCOPE, AND APPLICABILITY 3.1.1 Purpose The purpose of this procedure is to specify the steps required to generate CPC/CEAC project software and software design documentation. Adherence to this procedure is intended to avoid errors in the reproduction of a quality assured software system and its related software design documentation. 3.1.2 Scope This procedure covers the generation of CPC/CEAC project software and sof tware design documentation. The specific activities include generation of project software and design documentation through reproduction and modification of generic software. 3.1.3 Applicability These requirements are to be followed for the generation of new CPC/CEAC project sof tware and documentation. A prerequisite for application of this procedure is that all applicable generic software design documents and software have been completed in accordance with Reference 3.2.1. Revision 03 Page 56 of 60 1

3.2 REFERENCES

FOR SECTION 3.0 l f 3.2.1 Quality Assurance of Design Manual for C-E Nuclear Power Systems. l l 3.2.2 Software Implementation Procedure for CPC/CEAC, CEN-39(A)-P, Supplement 1-P. 3.2.3 CPC Protection Algorithm Software Change Procedure Supplement, j CEN-254(V)-P. 4 i i r 4 i Revision 03 Page 57 of 60 i

3.3 SOFTWARE DESIGN DOCUMENTATION GENERATION The fo' lowing is a list of software design documentation which will be generated for each project as needed; those documents marked with (*) will constitute'the minimum set. CPC Software Specification CEAC Software Specification Executive Software Specification CPC Functional Design Requirements Data Base Listing CEAC Functional Design Requirements Phase II Test Procedure Phase I Test Procedure Executive Phase I Test Procedure Phase I Test Case Calculations: Flow Test Cases Update Test Cases Power Test Cases Static Test Cases Trip Sequence Test Cases Comon Subroutines Test Cases Penalty Factor Test Cases Position Display Test Cases i Phase I Test Report (*) Phase II Test Report (*) Revision 03 Page 58 of 60

Test & Certification Analysis of the Core Protection Calculator System Software for Channels A & B(*) Test & Certification Analysis of the Core Protection Calculator System Software for Channels C & 0(*) Revision 03 Page 59 of 60

3.4 PROJECT DISK GENERATION A project disk will be generated using the procedure detailed in Reference 3.2.2 or 3.2.3. O Revision 03 Page 60 of 60

4 COMBUSTION ENGINEERING, INC. _.........}}

Retrieved from "https://kanterella.com/w/index.php?title=ML20151Z052&oldid=4148760"