ML20147F291
| ML20147F291 | |
| Person / Time | |
|---|---|
| Site: | Arkansas Nuclear  |
| Issue date: | 09/22/1978 |
| From: | ABB COMBUSTION ENGINEERING NUCLEAR FUEL (FORMERLY |
| To: | |
| Shared Package | |
| ML20147F289 | List: |
| References | |
| CEN-039(A)-NP, CEN-39(A)-NP, NUDOCS 7810190089 | |
| Download: ML20147F291 (56) | |
Text
..._
\\
ARKANSAS NUCLEAR ONE - UNIT 2 DOCKET 50-368 Cell-39( A)-NP o
CPC PROTECTION ALGORITHM SOFTk!ARE CHANGE PROCEDURE SEPTEMBER 22, 1978 k.
e Combustion Engincefing, Inc.
llucicar Power Systems Power Systems Group Windsor, Connecticut
.]
t
. /.
j'[
v, LEGAL ll0TICE
' This report vias prepared as an account of viork 7
sponsored by Ccmbustion Engineering, Inc. i!either Co:abustion Engineering-nor-any person acting on its
[
behalf:
4 a.
Makes any vtarranty'or representation, express or implied including the viarranties of fitness for a particular purpose or merchantability,viith respect
~
to the accuracy, comoleteness or usefulness of the information contained in this report, or that the use of any inforir.atica, apcaratus, method, or process dis-closed in this report may not infringe privately ovined rights; or i
b.
Assuces any liabilities viith respect to the i
use of, or for damages resulting frca the use of, any i
infonr.ation, appartus, method or process disclosed in this report.
y 8
6 e
g 1
e
. ~
w-<.am.-ee, ae.2,e s.&ws
=.we-*e--
4
',f ABSTRACT
. i This do'cument presents procedures to-be followed'when specifying and imple-menting modificationsLto quality assured CPC/CEAC software and documentation.
Section 1.0'of this document contains procedures applicable to specifying i
I modifications to the CPC/CEAC protection algorithm functional design:and Section 2.0 of this document contains procedures applicable to data base.
implementing and testing changes'to the CPC/CEAC system software design and
.Section 3.0 contains procedures applicable to. the creation of data base.
project specific software and documentation from the approved generic
~
design.
I i
j i
?
- i..
4 i
- i i
' Revision'01 Page' 3 of 56 l
l
._..,_r. -.._..,,. _,.,_......,..-~_ _ e.
e m u
}
w-r l
~
TABLE OF. CONTENTS i
Page No.
Section Title 1.0 SPECIFICATION OF SOFTWARE FUNCTIONAL DESIGN AND 6
DATA BASE CHANGES-P 1.1 PURPOSE, SCOPE AND APPLICABILITY 6
6 1.1.1 Purpose-6 1.1.2 Scope 7
i 1.1.3 Applicability 9
1.2 REFERENCES
1.3-DESIGN INTERFACES AND MODIFICATION 10 REQUIREMENTS 10 1.3.1 Design Interfaces 1.3.2 CPC/CEAC Protection Software Functional
~13 Design Changes 1.3.2.1 Specification of CPC/CEAC Protection Algorithm Software Functional Change 14 1.3.2.2 Transmittal of the Change 15-1.3.2.3 Revision of CPC/CEAC Functional 19 Descriptions 1.3.2.4 Revision of Plant Data Base Document 20 1.3 2.5 Recertification of CPC/CEAC FORTRAN 20 l
Simulation Program 1.4 PHASE I DESIGN CHANGE QUALIFICATION 21 TESTING 2.0 IMPLEMENTATION, DOCUMENTATION AND TESTING OF 27 SOFTWARE CHANGES 2.1 PURPOSE, SCOPE AND APPLICABILITY 27 27 2.1.1 Purpose 27 2.1.2 Scope 27 2.1.3 Applicability
2.2 REFERENCES
FOR SECTION 2.0 29 2.3 SOFTWARE CHANGE PROCEDURE 30 30 2.3.1
~ Origin of Software Changes 30 2.3.1.1 SCR Log 31 2.3.1.2 Software Change Request-2.3.2 Implementation of Software Changes 31 31
+
2.3.2.1
$CR Signoff 31 2.3.2.2 SCR Review 32 2.3.2.3 SCR Implementation 2.3.2.4 Review of SCR Implementation 35 35 2.3.2.5 Disk Generation 37 2.3.3 Quality Assurance of Software Changes 39 2.4 PHASE I TESTING 40 2.5 PHASE II TESTING j
2.5.1 Description of Phase II Testing 40 41 l
2.5.1.1 Input Sweep Test 42
'2.5.1.2.
Dynamic Software Verification Test 7
t'
~
Revision 01 Page 4 of 56 weer.
w y-4
/
-w..m.
a #.ej vgy,,.,.p.
,e, c,,,ep.,p,,
f
., e.p, re,,p +4g; p.
f,
i TABLE OF CONTENT-(Cont.)
-Page No.
Section.
Title 2.5.1.3.-
Live-Input Single Parameter Test 43 2.5.2
. Description of Test Case Selection 45 2.5.2.1 Input Sweep Test Case Selection 45
'l 2.5.2.2 Dynamic Software Verifi( tion Test Case Selection 45 1
i 2.5.2.3 Live-Input Single Parameter Test Case Selection-47 2.5.3
' Description of Generation of Acceptance Criteria 47 2.5.3.1 Acceptance Criteria for Input Sweep 47 1
2.5.3.2_
Acceptance Criteria for Dynamic Software; Verification Test 49 2.5.3.3 Acceptance. Criteria for Live Input Single Parameter Testing.
49 2.6 PROCESS NOISE EVALUATION 50 3.0 GENERATION OF PROJECT SOFTWARE AND SOFTWARE i
DESIGN DOCUMENTATION 52 3.1 PURPOSE,. SCOPE AND APPLICABILITY-52 l
3.1.1 Purpose 52 52 3.1.2 Scope 52 3,1.3 Applicability
3.2 REFERENCES
FOR SECTION 3.0
.53
- 3. 3 SOFTWARE DESIGN DOCUMENTATION GENERATION 54 3.4 PROJECT DISK GENERATION 56 LIST OF. FIGURES Page No.
Figure No.
Title 1.1-1 CPC/CEAC Software Design QA Documents 22 1.3-1
-CPC/CEAC Protection Algorithm Functional Design and Data Base Modification Block Diagram-23-1.3-2 CPC/CEAC Software Change Request Form 26 2.3-1 Design /QA Activities 38 l
LIST OF TABLES 6
t Table No.
Title Page No.
~
46 2.5-1 Dynamic Software Verification Test Cases-1 k-i 1
Revision 01'-
Page 5 of - 56 y,
h
_i___-,,..,,,
, _. g. ;-_
.7 7 ~.
m m...x.
SPECIFICATI0t4 0F-SOFTWARE FU!1CTIO!1AL DESIGN AND DATA BASE CH 1.0' 1.1 -
PURPOSE, SCOPE AND APPLICABILITY 1.1.1 -
Purpose 1-The purpose of Section 1.0 is to present the relationships between various steps in the process of specifying modifications to the i
l CPC/CEAC protection algorithm sof tware 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 modifica-As tions is complete and is'_ accomplished in a structured manner.
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 cf a change to the CPC/CEAC protection algorithm
\\
software functional design and data base, including generation of I
test results from the CPC/CEAC FORTRAN code for comparison to the s
implemented CPC/CEAC software.
The process covered in this section begins when the specific details of a change to the protection algorithm t.oftware functional design or to the dat'a Revision 01 Page 6.of.56 A
)
,~,..,,,,,n,.-,
- =. -
-.,..,..~n.-,,
. -.=
=..
~
~
}
\\
base have been established.
The process covered in this'section j
Andswhenthefollowingdocumentshavebeenrevisedinaccordance f
with'the procedures given in Reference 1.2.1.
j 1.
Recorded calculations or other design analysis documents i
s 1
establishing specifics of the CPC/CEAC protection algorithm functional design or values of data base constants.
The CPC Functional Description; the CEAC Functional Description;-
j 2.
and thc CPC/CEAC. Data Base Document i
3.
The CPC/CEAC FORTRAN code.
4.
The Phase I Test Report-5.
The Phase II Test ~ Report 1.1.3 Applicability These requirements are to be followed for all modifications to the CPC/CEAC protection algorithm scftware functional design and 3
non-addressable constants that are made subsequent to. completion j
4 of design qualification of the CPC/CEAl, software and data base constants for a'given plant.
A prerequisite for use of these r
requirements is that all applicable CPC/CEAC design documents have previously been completed in accordance with procedures i-
}:
y Revision 01 Page 7. of 56'
,,yg,,._,,
,,p, 4
s aw.,.m.
- =
e n.
.n..,
,.,,_g i,.,.,_._._,_..h,'],_,,.
~
=
i f
given in' Reference l'.2.1, and together refle'ct the: complete QA'd status of software specification'and implementation for;a given plant.
The applicable CPC/CEAC.' design quality assurance,documenta -
tion for a given plant and the relationship between'the various design ' documents' are shown in Figure 1.1-1.
i r
e 5
)
f
\\
~
6 q
Revision Ol' Page 8 of 56 j
~
j j
i
- - -,,~
,s
e.
4 J
+
1.2' REFERENCES FOR SECTION'1.0-1.2.1 Quality Assurance,of Design Manual for C-E Nuclear Power Systems.
l
'1.2.2 Core Protection Calculator. Phase II Test Report CEN,-73(A)-P.
.i k
I P
\\.
~
4 3-
.Revis on 01 Page 9 of.56 i
2 1
l,
..,...,...,,.-rwnse++-~,-r.-~.~~.~.'- ~~ ~.n:.
-.~.~..r_'w~,,~ n.'..,': '.' "i.. "*?.'.~_* *...'2 "",".,m.'9 Y'...._' ',"._*, "_ IU
~:
q 1.3-DESIGN INTERFACES AND MODIFICATION REQUIREMENTS-
'The interfaces and activities' required for modification.of CPC/CEAC' design-documents and Phase I and Phase II design qualification tests are shown in Figure 1.3-1.
During modification toLthe
'CPC/CEAC software design and/or' data base constants, these documents are revised as required in accordance with procedures given-in-Reference 1.2.1 to consistently reflect the status of the mo'dified
-design.
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 associated with specification of the modification after the requirements of the modification have been established.
f 1.3.1 Design Interfaces The modification process is initiated when details of the modifi-cation have been established by the responsible C-E engineering group.
For these requirements to be incorporated and referenced by the CPC/CEAC Functional' Descriptions or Data Base Document,
\\
they must be completed as recorded calculations or other design documents in accordance with Reference 1.2.1.
After establishment of the details of the modification, a Software Change Request (SCR) (Figure 1.3-2) may be issued to the C-E engineering group responsible for software implementation.
As explained in Section 1.3.2.2, the SCR is designed to allow software implementation to
.be planned or to proceed in parallel with the completion of the
^
' Revision 01 Page 10 of 56
functional design QA process.
Although individual SCR's are not required by the Reference 1.2.1 QA process they are included
- herein for the following reasons:
o
- 1.
'SCR's are referenced in revisions to the CPC/CEAC Functional Description and Data Base Document to provide complementary information in the form of traceability to the record of revisions listed in these documents.
The references to the SCR's are contained in the reference sections of these documents and are of the form:
Revision i of.this' document implements the following_ Software Change Requests:
k,1,m...
where i = the document revision number k, 1, m = SCR numbers implemented.
2.
Individual SCR's provide. traceability, since originals are-
. retained in the' design files of the originating engineering group and copies are disseminated to the engineering group.
using the SCR's to begin software modifications.
N 3.
Details of implementation of SCR requirements including a V
Cha'nge Applicability Form are transmitted back to the originating design group so that confirmation that the SCR was correctly understood is provided.
A copy of the SCR form used for CPC/CEAC software. modifications is shown in Figure 1.3-2 and the Change Applicability Form is shown in Figure 1.3-3.
Revision 01 Page 11 of 56 n
Upon completion of detailed modification requirements in accordance with Reference 1.2.1, these requirements are referenced by the associated revisicn of the CPC/CEAC Functional Description and/or Data Base Document.
The revisions of these documents are discussed in Sections 1.3.2.3 and 1.3.2.4, respectively.
The CPC/CEAC Functional Description and Data Base Documents are revised in accordance with Reference 1.2.1 and are transmitted to the C-E engineering group responsible for implementation of the revision in the CPC/CEAC software.
For those modifications which impact the CPC/CEAC FORTRAN code, the CPC/CEAC FORTRAN code certification document is revised.
All revisions to the FORTRAN code are done in accordance with the requirements of Reference 1.2.1.
The code certification document is referenced to the appropriate revision of the CPC/CEAC Functional Description.
Revisions to values of existing data constants in the Data Base Document do not require alteration of the FORTRAN code, since the values of data constants ~ are not specified within the code, but are inputs to the FORTRAN code.
\\
For those modifications which impact the conclusions of Phase I and Phase II Test results, the CPC/CEAC FORTRAN code is used to generate expected results for Phase I and Phase II qualification tests.
The results of the FORTRAN cases are used in the revisions of Phase I and Phase II Test Reports.
These Test Reports will reference the appropriate revision of the CPC/CEAC FORTRAN code.
Revision 01 Page 12 of 56 n.
- )
' As shown in Figure'1.3-l', the Software'ChangeLRequest.(Figure
-1.3-2), the CPC/CEAC functionai descriptions, the CPC/CEAC data base' document,.and the CDC/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.2 CPC/CEAC Protection Softkiare 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 protec-tion algorithm software functional design and data' base.
The sequence of events is described from determination of the require-ment 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:
1)
Specification and transmittal of a functional' change and/or
\\
a data base change i
2): ' Revision of Functional Description 3)
' Revision of Data Base Document y
4)
Recertification of CPC/CEAC FORTRAN Simulation Revision 01 Page 13 of 56 L
b -
X
'5)
Change l Qualification 1.3.2.1-SpecificationofCPC/CEACProtectionAJgorithmSoftwareFunctional Change When a CPC/CEAC protection algorithm software functional design change has been identified and fully defined, it shall be trans-mitted to a CPC/CEAC Design Engineer responsible for execution of.
the CPC/CEAC functional design change procedure.
If.the change does not affect CPC/CEAC FORTRAN Simulation Code,:'the functional A
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/CdAC System simulated in the FORTRAN code,-the change will be implemented in 7
the CPC/CEAC FORTRAN Simulation Code according to Section 1.3.2.5.
When the CPC/CEAC FORTRAN Simulation _ Code has been modified to
\\
reficct the functional design change, a series of debug cases shall'be run to assure that no FORTRAN errors are present in the I
update to the FORTRAN code.
If FORTRAN errors are detected, they shall be corrected and the test cases rerun before the change is transmitted to the software implementation group.
The test cases will normally be Phase II static or dynamic test cases, Reference 1.2.2, selected to exercise the modified portions of the FORTRAN
. code.
Revision til Page 14 of 56
-1.3.2.2 Transmittal of1the Change a
, i
'The medium for transmittal of individual software functional design changes or data base changes from the software. functional group to'the' software implementation group.is the Software Change Request (SCR)' form shown as Figure 1.3-2.
The SCR supplements the formal quality' assured functional de'scription and data base
~
documents.
It is a'means of providing orderly communication between groups with design specification responsibility and.
groups with design implementation responsibility.
Quality assurance of a software design change is established by revision of the-CPC/CEAC Functional Descriptions and/or.the CPC/CEAC Data Base Document.
Revisions of the CPC/CEAC functional Descriptions and.
Data Base will have references to applicable SCRs as a supplement to the record of revisions required for these documents.
Completed SCR forms must be approved by both the functional design grotp and the software implementation group.
At the top of the form are blanks for entering the 'following information:
\\
1)
Change #:
a unique sequence number-for the SCR obtained by entering a line in the SCR Log.(see Section 2.3.1.1).
5
- 2) -Date:
date on which the SCR is filled out.
3)
Plant (s):
plant;or plants for which the SCRLapplies.
~
. Revision 01 Page 15 of 56 A -
m w
A
The remainder of. the SCR consists of six parts.
Guidelines for.
i completion'of.each part are provided below:
1.
. Originator:
Section and.name of the. person filling out the SCR.
a j
II. -
References:
.These;are documents giving the basis.for;the change or are other SCRs affected by this SCR.
III. Summary of Change:
If.the change is minor, it may be described t
in the space provided.
For more extensive.l changes a'descrip-tive phrase'is entered in the space provided, and a detailed description of the change is.provided on attached pages.
The change description should adhere to the following guide.
lines for each plant affected by the change:
?
1)-
All parameters are referred to by their functional.
description variable names.
l 2)
Arithmetic operations are described in standard mathematical
~l l
notation.
[
3 Y
3)
Logical operations, branching, and loops are described f
in' concise prose using relational operators such as'>,
5,,/,etc.
.o Revision 01 Page 16 of 56 a
e
i 4)
If necessary to avoid ambiguity in location of inserted or deleted operations, copies of flow charts from the current revision of the plant software specifications i
l should be annotated and included in the change description.
Copies of the old and new CPC FORTRAN Simulation coding may also be attached to avoid ambiguity.
5)
Constants and variables deleted from a given program by the change must be identified.
6)
Values for new constants must be given, and any new addressable constants must be identified.
7)
Any existing constants that have changed from protected to addressable status or from addressable to protected l
status must be identified.
8)
Changes in the values of existing constants must be stated.
IV.
Program (s) Affected:
List of CPC/CEAC programs affected by this SCR.
/
V.
Approvals:
1)
Prior to transmittal to the software implementation group the cognizant functional design supervisor or i
designate must review and approve the SCR.
Revision 01 Page 17 of 56
2)
Upon receipt of the SCR, the software impicmentation supervisor or designate must indicate his acceptance of the SCR by signing the indicated blank.
~
3)
The software impicmentation engineer implementing the change annotates the SCR to indicate any clarification obtained verbally and signs the " Implemented by" line when implementation of 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 for review of the implementation to verify correct interpretation of the SCR and signature.of the
" Imp 1. Reviewed by" line is obtained.
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 foi completion of the respective document enters the date of completion and the "Rev" number of the revised a
document in'the appropriate columns on the original of the SCR.
Revision 01 Page 18 of 56
1.3.2.3 Revision of CPC/CEAC Functional Descriptions 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 part.llel with software design activities that require substantial lead time.
Revisions to the CPC/CEAC Functional Descriptions required by an SCR shall be incorporated in accordance with Reference 1.2.1.
Upon final approval of the revised CPC/CEAC Functional Descriptions, lines VI A and/or VI B'(CPC Functional Description and CEAC Functional Description) of all SCRs encompassed by the revision shall be completed.
In addition, for all SCRs encompassed by the revision, any recorded calculation revisions or neir recorded calculations referenced by the revision to the fonctional descrip-tion (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 Descriptions shall be transmitted to the software implementation group to provide quality assured input for the revision of the CPC/CEAC software specifications.
Revisionni Page 19 of 56 m
r l
1.3.2.4 Revision of Plant Data Base Document
)
Revisions to a Plant Data Base Document shall be incorporated in accordance with Reference 1.2.1.
Upon final approval of the revised Plant Data Base Document, line VI C (Plant Data Base Document) 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 s
the revision to the data base shall be listed on line VI F (Recorded f
Calculations) and the revision number and date of completion of i
those calculations shall be filled in.
The approved revision of the Plant Data Base Document shall be transmitted to the software l
implementation group as quality assured input to the next revision l
of the CPC/CEAC software specifications.
1.3.2.5 Recertification of CPC/CEAC FORTRAN Simulation Program For CPC/CEAC functional design changes requiring modification of the CPC/CEAC FORTRAN Simulation Program, recertification of the l
code is required.
CPC/CEAC FORTRAN Sinulation Program recertifica-tion must be accomplished in accordance with Reference 1.2.1.
When recertification has been completed, the "Rev" number of the new certified version of the code is entered in the appropriate
/
column of line VI D in SCRs encompassed by the revision.
Revision 01 Page 20 of 56
P
- 1. 4 '-
PHASE I' DESIGN. CHANGE QUALIFICATION TESTING
. Phase I test cases to.be rerun shall be. determined.by the software implementation group and a definition of the test cases shall be
'provided to the functional ' design group.
The functional design.
e group shall execute the test cases using the CPC/CEAC~ FORTRAN Simulation Code and return the results to the icplementation group for. analysis and incorporation into the Phase I Test. documentation.
Further discussion on Phase I testing'is provided in Section 2.0.
a 4
/
Revision'0'I Page 21 of 56
RECORDED CALCUIATIONS FIJJ PUJER CEAC STATIC UFDATE CALCUIATION.
CALCUIATION CALCUIATION CONSTANTS DISTRIBUTION CONSTANTS DNBR.
CONSTANTS CONSTANTS CONSTANTS u
y-o,, r v
u PIANT CPC/CEAC.
I TC;CTIONAL DATA PASE DESCRIPTIONS DOCUMEIC
~
FUNCTIONAL DESIGN SOFTJARE DESIGN B.
y l
SPECIFICATIONS SOFTWARE DESIGN y
o CPC i
PEASE I TEST REPORT l
V y
OBJECT AND PERIODIC.
TEST DISKS CPC
[
~
PHASE II TEST REPORT y
TO PIANT
\\~
FIGURE 1,1-1 CPC SOFTJARE DESIGN QA DOCGGNTS
t DETAILED REQUIREIt!TS FOR MODIFICATION TO CPC/CEAC PROTECTION ALGORITW. FU:iCTIO:IAL DESIGN OR DATA BASE ARE ESTABLISIED P
y MODIFY CPC/CEAC FUNCTIONAL ISSUE S,0FTWARE DESCRIPTIONS AITD/OR DATA C_HANGEREQUEST(SCR)
BASE DOCUMEIIT L
~
u AS REQUIRED, REVISE At!D RE-CERTIFY CPC /CEAC FORTRAN CODE a
SPECIFICATION (SECTION 1.0) v l >
AS REQUIRED, RE-RUN AS REQUIRED, RE-RUN PHASE I TESTS PFASE II TESTS
~ ~~ ~~ ~
~~ ~~~~
AND REVISE AND REVISE
~~~
~ ~ ~
~ ~ ~
~~~
TEST SUWARY TEST SUWARY u
I l'
IMPLEMENTATION (SECTION 2.0) e
'P IMPLDENTATION OF SOFTWARE !ODIFICATION 1.
CPC/CEAC SOFD.'ARE SPECIFICATION 2.
CPC/CEAC ACSEELY SOURCE FILE AND LISTING 3
CPC/CEAC OBJECT AUD PERIODIC TEST DISKS
~
FIGURE 1 3-1 i.
CPC/CFACPROTECTIONALGORITHMFUNCTIONALDESIGN l
AtlD DATA BASE FDDIFICATION BLOCK DIAGRAM Page 23 of.56 mm
SHEET OF.
' Change #:
i Date:
Plant (s):
CPC SOFTWARE CHANGE REQUEST
- I.
Originator:
e II..
References:
III. Summary of Change:
(use. additional sheets if necessary)
.IV.. Program (s) Affected:
t V.
Functional Design Group Approval Softwar_e. Design Group Approval c
Implemented by Implementation Reviewed by; Figure _1.3-2
/
Revision 01; Page 24 of 56
~.
(
4 4
P
- SHEETJ '0F-SCR#:
- Date:
' VI.
FUNCTIONAL DESIGN DOCUMENTS 1AFFECTED-Plant: -
Rev -Yes No Date Completed
+
A.
CPC Functional Description
' B CEAC Functional Description
- C Plant Data Base Document' D
FORTRAN Simulation Code E
PhaseHII Test Report F
L Recorded Calculations:
9 E
3
~
i i
r I
i Figure 1.3-2. (Cont.)
' E Page 25 of 56 j
~
Revision n).
P
=*wv etw y-w.se
+
g-e e--e-f,
-e r
t w o-
,--wr
'w v e W 9-9
,r g'
r rTM w 4'-*-*
F*tF
'aso y
e
>,+ ver +, q, w
g 9 y /, me ye
~ "
Sheet of II98## l 3-3
~~
Date:
' Plant:
Initials:
CHAtlGE APPLICABILITY FORM DNBR/LPD CALCULATOR SYSTEM Change Completion Date and Initials Applicable Software Item Li. sting Source Object Specification i
e 9
S' I
e e
4
/
l O
l5 h[ p D ifr Ti
$np
2.0-IMPLEMENTATION, DOCUMENTATION AND TESTING OF SOFTWARE CHANGES 2.1 PURPOSE, SCOPE AND APPLICABILITY o
2.1.11
. Purpose-w
_ 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 software 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 software changes.
s 2.1.3 Applicability
~
Application of the procedures covered in this'section'is mandatory for modifications to CPC/CEAC software systems subsequent to-the initial design qualification of the software system.
A prerequisite Revision 01.
Page 27_ of 56'
for application of this procedure is that all applicable system design documents have been completed in accordance with Reference 2.2.1.
t
/
Revision 05 Page 28 of 56
i
2.2 REFERENCES
FOR SECTION 2.0 i
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 Singic 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 Rev. 01, Supplement 1-P. September,1978.
i l
l 1
i Revision 01 Page 29 of 56
~
2.3 SOFTWI.RE CHANGE PROCEDURE 2.3.1 Origin of Software Changes 2.3.1.1 SCR Log A software change originates when either the responsible functional design group or software implementation group identifies the need for a software change and obtains a unique software change request (SCR) number 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.
1 2)
The date on which the SCR is entered in the log.
3)
The originator of the SCR.
4)
The subject of the SCR.
A descriptive phrase defining the change to be requested.
5)
The initials of the implementor of the SCR and the date i
completed (i.e. programmed and debugged).
Revision 01 Page 30 of 56
2,3.1.2 Software Change Request After obtaining an SCR number, the cognizant engineer in the originating group generates a Software Change Request, the contents 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 Signoff-
.o All SCRs will be signed off by the group supervisor or designates responsible for the software system requiring modifications.
This signoff is'to acknowledge receipt of the SCR.
2.3.2.2 SCR Review A signed-off 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 verbally, it will be recorded on the SCR and initialed by the cognizant engineer.
The verbal information will be highlighted by underlining or bracketing to facilitate.
validation by'the originating group when the annotated SCR is returned.
l-Revision 01 Page 31 of 56
2.3.2.3
- SCR Implementation:
The implementor will prepare, design, code, and implement the Software Change Request using the following procedures the details of which are contained in Reference 2.2.4.
o_
b When an SCR is ready for implementation, the implementor will prepare the software change package by filling out and attaching 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 implementor 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.
l-The software change package will be maintained by the implementor l
I until the change has been implemented and tested.
The package will then be returned to the originator for review.
The implemen-tation group will file the package in the CPC design file.
c After preparing the software change package, the engineer will design and impicment the required change as follows:
i Revision 01 Page 32 of 56 l
s-e w
~
-.-r-e-
m
--r
--w,-
-j 1)
- The most recent working copy of. the affected calculation descriptions, flowcharts, input / output lists, variable lists, EQU lists, and constant lists'of the System Software Specification will be marked up tofreflect'the change and initialed by the engineer.
i r
2)
The. required. coding ~ ch'anges will. be' marked on the most.
j i
recent working copy of the assembly listings.
When a new t
listing is created, the' previous version of the. listing will' l
be marked " superseded."
3)
The. Phase I. Test Cases will be reevaluatedLas detailed in Section 2.4 of this document.
i 4)
If the change affects scaled-fixed point coding, the appropriate'
-i scalir.3 recorded calculations will be revised accordingly.
I The software change will then be incorporated.in a specification i
i revision. The revised software design will'then be independently reviewed in accordance with Reference 2.2.1.
l i
o L
-l t
All CPC/CEAC source' files affected by the change will be updated,
- i..
i In the course of coding the changes, the following documentation j
' ~ ~
L will be performed:
i i
-t i
k
.j i
i l
Revision 01 Page 33 of 56 f
i
,,..,---,I
. - -., - - - - ~.
._~~-..-,~,.-,-.e.,-
r 1).
A' revision to CPC software consists of one or more SCRs.
i In the initial optiating of a source. file.during a revision, the revision number.of the source file'is incremented by
'1.00 and the decimal pcrt of the number is reset to.00.
In the implementation of subsequent SCR's within this revision, which result in at.other updating of this source file, the revision number of the source file'is incremented by 0.01.
2)
An "SCR Implenientation 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.
i 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 objectmodules.
To complete'a software change package and the implementation of-an SCR, the implementor will fully debug the generated oDject
, nodule (s).
If a program error is-detected during debug it will be corrected and all affected documentation, including the sof tware
~
' Revision 01 Page 34 of 56
~
~
change package, will be'modifiedLas. required.
The revision level,.however, will not be incremented for changes to correct errors in the:SCR implementation uncovprod during debug testing.
When the object module has been fully debugged, the implementor will complete the change package by attaching the' debug' test f
cases,' filling in the applicable columns in the Change Appli-cability Form and initialing and dating the SCR.
The implementor will then return the change. package to the cognizant engineer and will initial and date the SCR Log.
The cognizant-engineer will check the change package.for completeness and file the completed package.in the system design file.
t 2.3.2.4 Review of SCR Implementation An annotated copy of all SCRs will be returned to the originator with copies of the marked up calculation descriptions and flow charts.
The originator will then review the implementation and sign off the SCR to complete his design change package.
l L
2.3.2.5 Disk Generation The impicmentor will generate new. reference and~ test disks usirg l
o.
the following procedure the details of which are contained.in-l Reference 2.2.4.
s i.
Revision 01 Page 35 of 56 i
ll--.
P To generate' a new' reference disk, load modules will be created from object code.
These load modules wil' be written to disk'in 4KB blocks.
Each' block will occupy one disk track.
A disk track may be generated' entirely from revised object code, copied entirely from the reference disk or copied from the reference-disk with a revised' object overlay.
All tracks of a new disk will be initialized to all zeroes before any programs are written to disk.
Phase I and Phase II testing shall be performed on.the new disk
't where 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 established for the software system a test disk may be generated.
This is accomplished by re-assembling all source files,for the system-to generate new object modules.
An entire system load module will be generated from 9
these object modules and written to disk.
When all of the tracks of the test' disk have been generated, the test disk will be compared to the reference disk.
If differences are encountered, it will be determined whether the error is in the reference disk (i.e. an error missed by required testing) or r
the test disk.
The error will be corrected and the faulty disk will be regenerated in accordance with all applicable procedures for reference or test disk generation and testing.
If no errors Revision 01-Page 36 of 56 i
~.
~
Y
+
9
\\
1
'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.
Disks for shipment to customer sites for on-line operation will i
be duplicated from the system reference disk which will be maintained q
bycthe Software Design group.
The test disks will be similarly generated by duplicating the master. test disk. generated.above.
The master. test disk will be maintained by the Software' Design group.
I 2.3.3 Quality As'surance of. Software Changes The revised system functional descriptions and/or data base document are tlie design input to the CPC/CEAC software modifications.
Any r'evisions to CPC or'CEAC software are documented by revising l
f the system software specifications.. Quality assurance of the-final software implementation is established by independent review of-the 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.
i f
l'
[
l-9 Revision 01
- Page 37 of.56.
~
.. J. a.
,2.,_.....
,_m.
...--,-,e
?
Aett'tTTY -
f( '""]
)
AC0l%E SCR ff!)Mit.' Tt.if71N SCR 107 N)0T l
CCA 100 T
!!TP.T FI'q"tT7D Cl;A*rT.,
(
SCR l
cite.T FW!?/ ALL fc't*?'ITATTCS, 01707 A!.L h9 ATP;,1CAstLTTy E!;UIRS CliA?;7E. NFU.T A1.L Ei(Urn 13 i
y,o7.,.g g y - - -
fcPet TIF W A M W ATIO1,
a S
~ CPAN7.;g IT/DfTS CHAfi73 TQUTF@ TO BASE ffSIGN 3
FAcrA WJ Y.W.E Y
IE!!".I turn CFA?!75 EESIC?:TD A!D DOCtmTE 01 ALL SOMA. E DETA11ID DOC'M.:iTA!!C:4 t
CHA! ICE EEVIF D tt:C09tVFAT!0*: OF CFAfiCES DITO TIC BASE SfTCITICATION g0 m AEE LESIcx CAIft/IATIO:is y
I.tn;,1127 TEYTPJ OF tESITI DOCLW:frATIO:t in UU5ED TL*5CT10:tAL pg*;rrg ATPLICA!4LE RAPP -
ILEQtf1Rritf.XTS FOR DATA BASE Doct.T;;iT TIE E0P;'. AFE CFA!ME IS OfPW5.TED Ut E0'?CE 70 VAT.
CODE ASSESLY ASSD?tY LISTI:i1 A: D OMECi C00E IS PROVITED
+
"E8I# #
TII SOIT. ARE' CliA!!CE IS DEB'JOCED s
ETSL'LTS Y
-/
ST':'l 0FF SCR 14G E'T;'RY. Tite ALL l
PEQUDG tMitt D00'MATION T:3
- i g
CAM M PASTE TILE ElitFN IKrinE!;m 4 y
gCp yog yrgir/ To CRIGT1;A1CR ptsg CE!.TFATES A BritrED 6% STER DISK CTNERATION 150CWWE e
Y' II TTRFORM ALL RIttfrFD TFASE I TE!75 TEST PPOSrtSE TttASE I TLST t
ACCEPTANCE CRITDIA
, 9 DATA ICCtWfft FILASE I TEST PTSULTS RESLlLTS Dir.TPD.TET FICT4 0F PPASE I TEST REsttLTS t
ITRFORM ALL RIQtiFD fliASE II TTSTS 77 ggg FRASE !! TEST h
ACCETTA!i3 CRITTRIA g
LATA p
y ICCtM3T FPA!E II TEST EISL'LTS l TEST TE?tF.TS i
Y_.
Derrecnv Frnre er TvASE 11 Test I'"YC#
Rett /LTS t
STORE TAcrNP Fi!J.S I't A ELTARATT/
DtfrL1CATE PAS 117 10CKS STORAGE ASTA FI!JS t
ASSEMBII rACEur l
A:SEntt j
I t__.
j D15K t;E;;nATE TIS TFtf DISK 5 TPCM PACKVP Cl13YAT10ft MSIGLY A*tD CLSFMTf' 1HC FIELD DISKS Th0M -
1Y0CW4E THE HAS1tR D15K5
+
in)trN lt<ATTT; BY !!YATION TCTS in!OD1C T):St TO VGI'r Y filLICATt3 O!5A5 TO THE SITE F Sitir Titt. F1CLD LOAh ptsKF AND fitLD rial 0DIC TEST titSKS i
trrir;'1/CA A*fiVITf?S Figure No. 2.3-1 we.
+
2.4 PHASE I TESTING Phase I testing will be performed to verify the implementation of modifications to the CPC/CEAC Software.
Implementation is defined as the translation of the system functional requirements into modules of machine executable code, and the integration of these modules into a real-time software system.
Phase I testing is performed on relatively small, single-entry / single-exit segments of code called modules.
Any modifications to a program's code will require the regenera-tion of the entire program.
All of the modules that were modified will undergo a complete rerun of Phase I testing.
Test case inputs will undergo reevaluation such that each functional.
branch and each instruction in the affected modules is exercised.
Program wide test cases will then be run to assure correct generation of the program.
Any modifications to a program data base will require regeneration of the program constants.
All of the modules of a program which access the affected constants will undergo a complete rerun of Phase I testing.
The program containirig these modules will then be Phase I tested with the program wide test case inputs.
All Phase I test occumentation will be revised.
This includes the test case selection calculations and the Phase I Test Report.
Revision 01 Page 39 of 56 i
~'
[
y All Phase I Test' documentation wil1 be quality assured' including independent review in accordance with Reference 2.~2.1.
Details of Phas'e I testing are provided in a Phase'I Test Procedure.
2.5' PHASE II TESTING
'2.5.1 Description of Phase II Testing 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 l
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.
L Revision 01 Page 40 of 56
~.-
1 The Phase II testing uses the CPC/CEAC FORTRAN simulation code as a basis a.r comparison.
The results of Phase II testing including test case selection and acceptance criteria are included in the Phase II Test Report.
2.5.1.1 Input Sweep Test The Input Sweep Test is a real-time' exercise of the CPC application software and executive software with steady-state CPC input values read from a storage device.
The Input Sweep Test has the following objectives:
(1) To determine the processing uncertainties (of the CPC algorithms as used in the CPC/CEAC system hardware) that are inherent in the CPC design.
Processing uncertainties are defined as those resulting from differences in machine precision between f
the system hardware and the CDC 7600 (on which the FORTRAN code is executed).
The processing uncertainties will be factored into acceptance criteria for the Dynamic Software Verification Test, and Live Input Sinole Variable Test, and into CPC data base constants affected by these uncertainties.
1 (2).To verify the ability of the CPC 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,
' Revision 01 Page 41 of 56
4 (3) To complement Phase I module testing by identifying any, abnormalities in the CPC algorithms used in the system hardware which were not uncovered previously.
,.i._..
1 This test is performed using the CPC software overlayed with Input Sweep software, using unused portions of memory and a portion of the Executive Initialization Task for the overlay; the CPC application programs to be tested remain unaltered.
The Input Sweep software allows test case input values to be read l
from a storage device.
A large number of static test cases are selected which cover the range of CPC operation, ' including the upper and lower limits of all CPC inputs.
These test cases are allowed to initialize, after which calculated parameter values are compared off-line with expected valuci generated with the CPC FORTRAN code.
Dynamic Software Verification Test (DSVT) 2.5.1.2 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 '01 Page 42 of 56
4 i
j 1.-
To verify the dynamic: response of the integrated CPC sof.tware is consistent with that predicted by design analyses, and 1
t 2.
To supplement design documentation quality assurance, Phase I module tests, and input sweep tests in assuring correct o
impementation of software modifications.
The Dynamic Software Verification Test (DSVT) is similar to the Input Sweep Test in that special software is overlayed'onLportions of the executive software and on unused portions.of memory, e
t
. leaving the CPC application programs unaltered.
Like Input Sweep, CPC input' values are read from a storage device.
liowever, the Input Sweep Test uses CPC input values that do not vary, such that'each test case initializes to a steady-state condition.
DSVT (after initialization) uses time-variant' test case input' values to more thoroughly exercise " dynamic" portio's (recursive-n or time-derivative equations) of the CPC sof tware.
2.5.1.3 Live Input Single-Parameter (LISP) Test The LISP test is a real-time exercise of the CPC/CEAC application i
and executive software, with transient CPC/CEAC input values generated from an exte'nal source and read through the CPC/CEAC input hardware.
The objectives of this test are:
i 9 1.
To verify that the dynamic response of the integrated CPC/CEAC software and hardware is consistent with that predicted by 1
j design analyses.
s q
Revision 01 Page 43 of 56 c
,.[r-,-.
.y,,
-n.
oe.-
,,,..c5,
..,,.s, 3y
,--y.
-,,.y
,,,.m-4 g.+:
y
m I
f 2..
To supplement designLdocumentation quality ass'urance, Phase i
I module tests,. input sweep. tests, and DSVT testing in
- assuring correct implementation of software modifications.-
3.
Evaluate the integrated hardware / software system during operational modes approximating plant con'itions.
f d
~
Unlike Input Sweep and DSVT tests, the LISP test' employs no
[
special test software for generating test case input in'the-I CPC/CEAC system.. Dynamic test case inputs are generated by.
external test equipment to produce " live" analog and digital-signals that'are input to the.CPC/CEAC input processing 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 I
higher degree of precision in test acceptance criteria.
All dynamic portions of the CPC/CEAC algorithms ~ will be exercised with LISP tests.
i Reyision 01
.Page 44 of SF
2.5.2 Phase 11 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 minimum of 500 cases which cover the region of CPC operation, including upper and lower limits on CPC inputs.
Variations in values of selected addressable constants are incluaed. -The selection is designed to ensure a high confidence level in determination of processor uncertainty, anomaly detection, and initialization capability.
The spectrum of selected cases.
must therefore be based upon a sufficiently wide spectrum of cases covering the range 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 casa 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 thoroughly testing those portions of software that have been modified.
i Revision 01 Page'45 of 56 q
l
m
- 6 i
Table 2.'5-1
' t 1
' Dynamic Software. Verification' Test Cases ~
a P
1 t
i e
+
h r
4 I
.- i k
4 r
4 Revision'01 Page 46 of.56.
f
... ~,. -
_ - o....
r
-i -
I G
w~
r-w-
m'
..w
, - - -, -i---
,4
,u.
w e-
-r,-*,,r, my
%-4-.yp-,
,7-
~-
t
,r
The DSVT test cases for a given software modification will, as a minimum, consist of-cases 1, 7,12,16 and 25 from Table 2.5-14. which includes design basis. events.
Depending on the nature and complexity of the modification, additional cases from Table 2.5-1 will be selected as necessary to exercise the particular portions of the CPC software that have undergone modification.
2.5.2.3 Live Inpt.t 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 Acceptance Criteria As stated in Section 2.5.1.1, the Input Sweep Test has three o
objectives:
(1)- Determination of processing uncertainties.
I Revision 01 Page 47 of 56
~
(2) Verification of initialization.
(3)
Identification of abnormalities.
S.
)
i
[
Revision 01-Page 48 of 56
\\
)
2.5.3.2 Acceptance Criteria for Dynamic.Sof tware Verification Test i
~
P l
2.5.3.3 Acceptance Criteria for Live Input Si'ngle Parameter Testing 4
Page 49 of 56 Revision 01
~
2.6 -
PROCESS NOISE EVALUATION g
i Software changes will. ce. evaluated for their potentia 1Tt'o signifi-3 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)recursiveortimederivativecalculations,(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-i acceptable.
In the event that noise testing is necessary,'the tests will be per-formed by adding noise signals to the nominal (static or dynamic) values of selected simulated process inputs to the Single Channel System.
These inputs include pumpspeeds, temperatures, pressure, and excore detector signals. To the extent practical, the' noise signals that are used must be the best available representation of actual plant mise, with the preferred source being Ffi tape 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 l
Revision 01 Page 50 of ' 56 a-
4 (having frequency and amplitude characteristics similar to acutal r
pla'nt noise), orirecorded noise from non-CPC/CEAC plants.
4 The n6ise generation capability of the Single _ Channel Test Facility l
includes a 16-channel FM tape recorder and. appropriate amplification equipment to enable the CPC/CEAC single channel-system to use recorded a;
in-plant noise as part of the noise evaluation. Random 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 broad range of frequencies and waveforms.
e Acceptance of_ the noise response test results is based upon (1) determination that any non-conservative (relative to the noise-free condition) DNBR or LPD values are accommodated by measurement uncertainty allowances'in the-protectionalgorithms,and(2).determinationthattheplantavailability will not be unacceptably impacted by the altered noise response.
l C
l~
l
]
Revision ~01 Page 51 of 56
.m-.
w niw...
a
.<y
.a.-
~
... esa 3.0 GENERATION OF PROJECT SOFTWARE..AND SOFTWARE DESIGN DOCUMENTATION 3.11 PURPOSE, S' COPE, 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 software 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 software and documentation.
A prerequisite for 1
application of this procedure is that all applicable generic i.
software design documents and software have been completed in accordance with Reference 3.2.1.
l' Revision 01 Page'52 of 56
~ ~ ~ ~
~
[', ~
~
L i
l:
(
3.2 REFERENCES
FOR SECTION 3.0 3.2.1 Quality Assurance of Design Manual for C-E Nuclear Power Syster:ts.
3.2.2 Software Implementation Procedure for CPC/CEAC Protection Algorith:n, CEN-39(A)-P, Supplement 1-P, Septerber,1978.
O Revision 01 Page 53 of 56 h
j
'1 l
s I
a 3.3' SOFTWARE DESIGN DOCUMENTATION GENERATION-
-The following is a list of software design documentation 'which L
1-
- will be generated for each project.
4 I
CPC Software Specification
.CEAC Software Specification Executive Software Specification CPC Functional Design Specification Data Base-Document CEAC Functional Design Specification Phase II Test Procedure Phase I Test Procedure Executive Phase I Test Procedure Flow Test Cases Update Test Cases.
Power Test Cases Static Test Cases Trip Sequence Test Cases Common Subroutines Test Cases i
I*
Penalty Factor Test Cases Position Display Test Cases t
Phase-I Test Report Phase II Test Report
-Test'& Certification Analysis of 1
the Core Protection Calculator-
, System Software for Channels A & B
.q Revision 01
.Page 54 of 56 -
i Test & Certification Analysis of the Core Protection Calculator System Software for Channels C f. D W ng 4
i l
l I
I r
i 1
i
- 1 h,
l Revision 01 1
Pape 55 'or56 j
9'
f 3.4 PROJECT DISK GENERATION A project disk will be generated using:the following procedure the details of which are contained in Reference 3.2.2.
A new disk is formatted and initialized.
The source and object y
j files on the generic disk are then copied to the project disk.
l l
l l
- e l
I i
1 4
Revision 01 Page 56 of 56 I,