ML20112J718

AP600 Instrumentation & Control Hardware & Software Design, Verification & Process Rept

ML20112J718
Person / Time
Site:	05200003
Issue date:	06/30/1996
From:	Deutsch K WESTINGHOUSE ELECTRIC COMPANY, DIV OF CBS CORP.
To:
Shared Package
ML20112J711	List: ML20112J718 NSD-NRC-96-4737, Forwards WCAP-13383 Rev 1 Describing AP600 Instrumentation & Control Hardware & Software Validation & Process.Document Closes Open Item Tracking Sys Items 1038 & 1039 for AP600 Design Certification Project Dser Chapter 7
References
GW-J1R-002, GW-J1R-2, WCAP-13383, NUDOCS 9606210021
Download: ML20112J718 (39)

Text

_m wwqmyh;yp mghnwm:g:p mw @y~ r,,a, wo

@, n og o w w w.w_ n. wmmn -n mpp e y ~ypw ge m, + w? e- me u ;p;;

asp m m mP' y*- @sz w -

lM W@g u Mg$afSwp y 4 eMMMgb 46 4619W -

'"U h ws w ogy@m Q pq .

M < uwhyghmm m; m 'y y" s g- "o~

'e w wkgqw, i [ %y%s.ga% yyd% w ~ msg . e ,

' L M

• y[

+

h f}Y$ $$nygh N?[ Y D D M TQ ~M ?D E M ik ,J M Ef T $ /M @ . '

Mf0 h 0 YW!

• Qf_Oq L ,

%%'Sh!$&hl&&

$n&nqMm_mm&_estlyb_&

W ;W &.

ions N(&$f ' kh lah.V My wj;Wu  : qm,onkreprietary Cp / o.. .s m las($ 3b4 & W $ h ; gsh%. $

MBQ

p. #w h hbp & kb  ? h S/ ohM:lu h '

hh

%cdip:gdha%emMMgy&.QY %g . ;W3 nw.Wng - ws i

7 g . p

.. myy %,@qgm g. %l%s,:.a w

>?&e;s w n y momp - r ~

7 a, m d d *

&;L py H D7 1 ' - n +4 MlMp f.

M, w D@%y(Ax4@d 7W ph&2 rMf9Ms LbM% l$ng?w% mn w P Ty Nr sp L mQQSq, iW m I pt%. <

r*

y[ggm%.(%@+w&y Unn

,m'3%P 3Rpq: y.g-f t p 'isu,[- mW wl-g. ,

- -+m s,oi

, nf yp; .

, pgb a  % p s u: y p;; y &g - , , 3' -

se n ~ 2.g'

. Q374 ggg%p  ;

p y;& g n. a < ::4 ' ew: :h y *

/ y ., ,o, gy%

f , 4ylps.ua M. .m:% %[g@gw qQ9Q;V , N:-ir,p@2 l , _i .. .s by W W

'gs Aq.y n ,: # ,9 app;p9.3pt$f y sm wy .,m .- >

• * * , _ . D

, ;U Q y e,Wpp, s, n y %wW 8v c: 3

&% y %I%q3 ' ptyC + q' %gy +-xg..f Wtf%yY w %xm

?qh-Qs[jMm.WM},p@h.WWlNQf%ln. f.&vu ff l3 ;ym;)k, yy %$ y n.p.; b fihy r

m p-L3 _g&u;l &a Ma-Qek~ %. %_ m%n%u%n%e . G%.n& f fhw sw ~ .

w.m. c um y

.hn.e!b,%v ig, hm . pmqnd e

m d ye%r;W%.

. yn- 3 1 o 1,sy 2

' .L+W:

t.a y M ; u; s

q ~9pusmew a+

m.

ggn:4+q#.

2

- ~z.m m

g4 _p.,1~ w,a"h ,<

w mpy.wu vm: cn

a. A, c.w us , .. .u q. s v,,-,a, .

~ ~ ~ '

i&s ~m~ o v, a m.mg c

m y3

/.-,

,mw:,Y pa tg Q .;. f? '

g neef .d4:#

s '. .

m t &. w cw . al,"n Uy; WWN . m r s

dwQ,uQ;W 4pA 3 ;7fm[m%qp es b, y, %p'a ,y, r 'T ~

y~+4;p* .c.m%y+,- -Q.g u;n,;n

. LW W 1,,' ,g,44Jkr.M.

e a.};o p}! m; % ~2 -

< m .;pggnm+ L Q- m R wnm ;gsL y@g;rf;[pl p^ a. ;n . n w'p,p )4 e y

y)y 8( , . 9 m.f9,n ,,a p n,m_m ), s

• Jc a 'K $ ' a. g'f w ,

_ e %, vs a,u

. , .vgpp nn, , L . w,h{

g}y: e [Q 3 f n > m .y,y LW' ..y~m.

'y s m c.p t p y w;+w&;%y;;n,Qg,':,sy g.m.L.

asA  :-r -e Mu tt f,?yp p 6, < .&.

u -

1 s

7w w urn

,a, v

',v . r, W @pM-Shg m.e6..m ic w$t p WM m.-c Wv1M.o n ntT +ph, W:~r mE >:m y ,,wgg u, g%c'~ . , , w y,  %,..r,L;M-Q&(wpW%id v s g4 y r y D,,y yi,;< &w Msp MPs my .n?',_ e

' a&e n mv

- . w_ . Y-m #' .y.m.~',,4.t'. >H ,,b4, 'Ups in'

?

. . ,e w

' o

q

• m ,4 y ,[ ,

A-M a ~- m  ?.

g%b -: %V%e'? '~, Shj p;h s .J % ~z ' '. hj.Q. Qiu ._% K MQ . \ l;y* }

dd [O t i

[

dyMb Ml%wuh'dMUN; wh or3h $hfC'

$M' J f f)_((c &.g. * $l $ ii + $ Y' mEh mM a:n  % -n n?

3 ma3 M A R n 6 W G,$

0 0 , w M # n n M W %u?,mmmcC M ;.

L ;A[. ,ww w O[p ,. niw g_ v'

.44 n. qqw E3 MgH@m$L:

maNSTRUMENTATIOE 4mu s n m am- e, w- a w m m, n g s amw EsMAN+n.EGONTROg.EDUN 3

mupegwwww4 unum  %@- K EMHARDWAREMNDER

% Aw w n newnmyw

. MW wn aRMSOMWAREiDESIGNR an ex un .nsma w%ngM NfD.4 N~mD nm R.

kd8.

MxhdMEN~Isidd+ TID,p%p+@

m&w, A ro

~

mu~ %y' m:w s v"wn, n a M:WWa - .an-W W Ls cp '~

W~~W;&m,~ ROEESS$REROR. ym M~mM.

w3n wW~m,e _ ;e nm w u L.

e n- _

o 3:: , , A . , y my -

M@pAyg,12,g#.

+cm w2 a u m::m a.

SAP m u 6005DOEGWsJ1R4002

=%e, ,.a h, ,

n .' ', , ,

<',.,, y

~

U Nf,% %a

>o mm ;g.

mm,q ~gn gsg g, g y,s o .,

g '4 m.-- 4 e y

Me req s 3 ,

w : w.n 4

e ;, ; s :q w., S. n . a. <, -

<* Am A i

q-@. g% >d w:-y hm.j,;g& &m$T$% Yr M?p?iW Wiur%; h q a c x n Am a %m N;s;;

4 s

,4 '

mWy&:W' n m na +

. :; 1 e

, Whk e ~.

Gy$n$,

x

>, . $.+

s

% *' ~

ST S.w= 0h +cv *

'q% lijm Lw. e$j-[m UR d)_M , & dbI1%s,j A ?,b

%;[i 9,w:$%w" , ' ' M 5 "w(J b E -

,c@

w,a l%wMs,.$e .

s m.. 4;w, g m A?on.f.yE' c

<7a: s

, >p 9p9 q w', ec..ylN 4

. n< '_a. v#n

'l' n am,w W -

~ 4wR, ,, > Ywm_  %> &n%s ,m? v%pv i .

WR@m;%~,d, w14w y,m.aw& > , >ww+

1-

+ <m, L n.-

>%y.

' n4

• m:m,

.c% /m%r ' <r W %+>^  ;; -

u ve w m" 4 u.o v i  ! y

• t .w- n% . m +r qw

-Q mop.m(;3 L h, ? w%%.W m F c 3

> J ft , *;

p' s

.m w7 h (p :,My g

c o%w: f gp 'm,.m.h 8g' s , s 1 , e n;@+.  ! -Q_'  : yp) .: p.

s s.

s y

_ :p.s p p'q.(.

p  ;;

9.;g;4,m 2 ,m;.x a '(e 9 q t 7'p '

m.a w m n gju m,ho m%pgy-m%fygg

.m fy u Am - arc g W

,e 4 mn %4 yr

> rma.x 1

nw:6 ;igbr e &p.3 i i ; J , ,i c imt;h n 4 u.7&--

mgt s c+ , ,

, s,o p g " ytg , , u k.

i v

ggl 'l; Q

~

f bqKg n Ng',, y*iy WQ;p

%www-,Qg%qifyg. nw- ~.gaw< qu :u9pv.,.,%yp ,)r y;pp.tn ,p94;n%gQ v;; i:

t n

.w w.~/ ,o gw w:n,awm,~[ s*;m .x.m sen 2 +

u. + v ae i m .-

, %sy. m. , o -..w a v ,

, v..

y & r m., + .,. . >_ny t .synt u m , , e .s.

,s

%y 4 e q;mys 7 r., .

s.g n

49. a._ g n M@f;. x,MN,ylpkifiNNdMy +,_s%.nMEWeYg%hdiM 7 Mg/gpp W% 6:<g W ' Qr

. amun W d, v'.m@%y9 ,

$hkN .Nh ONhTh z G Q $Y A Q3.M V y[ g)C $

W ;m m.h @;s ig ms p Ne 4 r.cmcw#w M &mq m

v%w<m y g@h a y awhh Mm - m - w*

b A.-.,b $ [ k Uh 2@%~<->vg/

'q; swe= < .c w - 4@ w1 -

c

,a* y'

% 4;"m A p s w* "

%a .e:% fwJ&@nJWMp V 1 ~M.m .&~a oA b  % i e 7

N32#

1 MpfMMSMWMM @MMW6 ' ' - _' Ns ys M' Mp s s, D*

sg 9606210021 960617 kggm tq @d~ $ ex My M ' s M~

1  !

fM PDR ADOCK 05200003 10 ;;p +

Q Mg 3 < &@ - l@%

% A PDR gg ?f.

~

hh%f%- %. . %m%%N$h%h.N,N][,bd -

m mm h hg mm k J.f mb b, ((h.., m ,

1 4

,k, ,

Westinghouse Non-Proprietary Class 3 WC AP-13383 '

$ $ $ $ $ $ $$ Revision 1 AP600 INSTRUMENTATION AND CONTROL HARDWARE AND SOFTWARE DESIGX, VERIFICATIOX, AND PROCESS REPORT AP600 DOC. GW-J1R-002 Westinghouse Energy Systems A

8en888u:88s PDR

. WESTINGHOUSE NON-PROPRIETARY CLASS 3 2 l,

WCAP-13383 Revision 1 AP600 instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report AP600 Doc. GW-J1R-002 June 1996 WESTINGHOUSE ELECTRIC CORPORATION Energy Systerns Business Unit P.O. Box 355 Pittsburgh, Pennsylvania 15230-0355

@ 1996 Westinghouse Electric Corporation All Rights Reserved m:\2977w.cyc1b&14%

]

AP600 DOCUMENT COVER SHEET TDC: IDS: I S Form 58202G(5/94)[0058_new:1b] AP600 CENTRAL FILE USE ONLY:

' RFS#: RFS ITEM #:

0058.FRM AP600 DOCUMENT NO. REVISION NO. ASSIGNED TO Page 1 of f GW-JIR-002 - 1 l ALTERNATE DOctiMENT NUMBER: WORK BREAKDOWN #: i

~

. DESIGN AGENT ORGANIZATION:  ;

PROJECT

AP600 \

q ,

' ~ TITLE: AP600 instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report l l

l

' ATTACHMENTS: DCP #/REV. INCORPORAT$D IN THIS DOCUMENT I

REVISION:

l i

l I i

! CALCULATION / ANALYSIS

REFERENCE:

l ELECTRONIC FILENAME ELECTRONIC FILE FORMAT ELECTRONIC FILE DESCRIPTION m:\ap600\2977w.wpf Wordperfect 6

(C) WESTINGHOUSE ELECTRIC CORPORATION 1996 0 WESTINGHOUSE PROPRIETARY CLASS 2This document contains information proprietary to Westinghouse Electric purpose for which it is fumished and retumed upon request. This document and such information is not to be reproduced. transmitted, disclosed  !

or used otherwise in whole or in part without pnor written authorization of Wesunghouse Electric Corporation, Energy Systems Business Unit, -

subject to the legends contained hereof.

O WESTINGHOUSE PROPRIETARY CLASS 2CThis document la the property of and contains Proprietary Informa suppliers, it is transmitted to you in conRdence and trust, and you agree to treat this document in strict accordance with the terms and conditions of the agreement under which it was provided to you.

@ WESTINGHOUSE CLASS 3 (NON PROPRIETARY)

COMPLETE 1 IF WORK PERFORMED UNDER DESIGN CERTIFICATION ,OR COMPLETE 2 IF WORK PERFORMED

-UNDER FOAKE, 1 @ DOE DESIGN CERTIFICATION PROGRAM - GOVERNMENT LIMITED RIGHTS STATEMENT ISee page 2]

Copyright statement A license is reserved to the U.S. Govemment under contract DE-ACO3-90SF18495.

O DOE SubjectCONTRACT DELIVERABLES to speci6ed exceptions, (DELIVERED disclosure of this data is restrictedDATA) until September 30,1995 or Design Certification under DOE contra 90SF18495, whichever is later.

EPRI CONFIDENTIAL: NOTICE: 1 0 2 30 4 sO CATEGORY: AE B C D0 E F0 2 O ARC FOAKE PROGRAM - ARC LIMITED RIGHTS STATEMENT (See page 2)

Copyright statement A license is reserved to the U.S. Govemment under contract DE-FCO2-NE34267 and subcontract ARC-93-3 SC-001.

! [ ARC CONTRACT DELIVERABLES (CONTRACT DATA)

Subject to 5+?-4 exW disclosure of this data is restricted under ARC Subcontract ARC-93-3-SC-001.

EIGINATOR SIGqTUR TE j K. L. DeutSCh

. AP800 RESPONSIBLE MANAGER 3/ _

SIGNATURE *

,[ 31 d h i'3 APPROVAL DATE Md i J. B. Reid M_ g (-//-fg Approvai of m ,.sponeme manager signm.s mi document isempi.. er.d revi.ws ar. #, .ctronic nie is atiacneo and document is released for use.

l

- m:6.fmt:1b$62006 -

l

i AP600 DOCUMENT COVER SHEET Page 2 -

4 Form 58202G(5/94) LIMITED RIGHTS STATEMENTS DOE GOVERNMENT LIMITED RIGHTS STATEMENT (A) These data are subtrutted with limited rights under govemrnent contract No. DE-ACO3 90SF18495. These data may be reproduced and used by the government with the express hmitation that they wiu not, without written permission of the contractor, be used for purposes of manufacturer nor disclosed outside the govemment; except that the govemment may disclose these data outside the government for the following purposes, if any, provided that the govemment makes such esciosure subject to prohibition against further use and esclosure:

(1) This " Proprietary Data' rney be disclosed for evaluation purposes under the restrictons above.

(II) The

• Proprietary Data' may be disclosed to the Electric Power Research Institute (EPRI), electric utihty representa#ves and their direct consultants, excluding direct commercial -v&s, and the DOE National Laboratories under the prohibitions and restrictons above.

(B). This notice shaR be marked on any reproduction of these data, in whole or in part.

ARC UMITED RIGHTS STATEMENT:

This proprietary data, furrushed under Subcontract Number ARC-93-3-SC-001 with ARC may be dupbcated wxi used by the govemment and ARC, subject to the Hmitanons of Article H-17.F, of that subcontract, with the express limitations that the proprietary data may not be deciosed outside the govemment or ARC, or ARC's Class 1 & 3 members or EPRI or be used for purposes of manufacture without prior perrrussion of the Subcontractor, except that further disclosure or use may be made solely for the fouowing purposes.

- This propnetary data may be disclosed to other than commercial compostors of Subcontra: tor for evaluation purposes of this subcontract under the restnction that the proprietary data be retained in contdence and not be further esciosed, and subject to the terms of a non-disclosure agreement between the Subcontractor and that organizaton, excluding DOE and its contractors, DEFINITIONS CONTRACTIDEUVERED DATA - Consists of docurnents (e.g. specifications, drawings, reports) Which are generated under the DOE or ARC contracts which contain no background proprietary data.

EPRI CONFIDENTIALITY / OBLIGATIONNOTICES l NOTICE 1: The data in this document is subpect to no contdentiality obligabons NOTICE 2: The datain this documentis and confidentalto lectric ' and/or its Contractors, it is forwarded to recipient under an obligation of Trust for limited purposes . Any use, ure to unauthorized persons, or copying of J this document or parts thereof is prohibited except as agreed to in advance by Electric Power Research Institute (EPRI) and W Electric Corporaton. Recipient of this data has a duty to inquire of EPRI and/or Westinghouse as to the uses of me information herein that are permitted NOTICE 3: The data in this document is proprietary and conAdential to Wesunghouse Electnc and/or its Contractors. It is forwarded to recipient under an obligation of Conhdence and Trust for use only in evaluation tasks authoriz the Electric Power Research inettute (EPRI). Any use, deciosure to unauthorized persons, or copying this document or parts thereof is except as agreed to in advance by EPRI and Wesenghouse Electnc Corporatinn Recipient of this dets has a duty to inquire of EP i and/or Westinghouse as to the uses of the information contained herein that are permitted. This document and any copies or excerpts thereof that may have been generated are to be retumed to Westnghouse, directy or through EPRI, when requested to do so.

NOTICE 4: The data in this document is proprietary and con 6dential to Wesenghouse Electric Corporation and/or its Contractors. It is beina revealed in confidence and trust only to Employees of EPRI and to certain contractors of EPRI for Nmited evalumbon tasks authorized by EPRf.

Any use, dieciosure to unauthorized persons, or copying of this document or parts thereof is prohibited. Ttus Document and any copies or Cxcerpts thereof that may have been generated are to be retumed to Weetnghouse, directly or through EPRI, when requested to do so.

NOTICE 5: The data in this document is poprietary and confidental to Westinghouse Electric Corporabon and/or its Contractors. Access to this data is given in Confidence and Trust only at Westinghouse facilities for hmited evaluation tasks assigned by EPRI. Any use, esciosure to unauthorized persons, or copying of this document or parts thereof is prohibited. Netther this document nor any excerpts morefrom are to be removed from Westmghouse facilities.

EPRI CONFIDENTIALITY / OBLIGATION CATEGORIES CATEGORY "A" -(See Denvered Data) Consists of CONTRACTOR Foreground Data that is contained in an issued reported.

CATEGORY "B" - (See Denvered Data) Consists of CONTRACTOR Foreground Data that is not contained in an issued report, except for computer programs.

CATEGORY *C" - Consists of CONTRACTOR Backgrourxl Data except for computer programs.

CATEGORY "D"- Consists of computer programs developed in the course of performing the Work.

CATEGORY "E" - Consists of computer programs developed prior to the Effective Date or after the Effective Date but outside the scope of the Work.

CATEGORY "F" - Cormsts of administrative plans and administrative reports.

m%p00the977w. fun:1tr0523e6

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

+

+

i b

l TABLE OF CONTENTS Section Title Page._

1.0 I NTROD U CTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 -1 2.0 ELEMENTS OF THE COMMERCIAL GRADE ITEM DEDICATION PROGRAM ........................................2-1 i 2.1 VENDOR ASSESSMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 l 2.1.1 Vendor Design, Verification and Validation Process . . . . . . . . . . 2-1 l 2.1.2 Software Quality Assurance (SQA) Plan . . . . . . . . . . . . . . . . . . 2-2 2.1.3 ' Vendor Compliance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.2 HARDWARE ASSESSMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.2.1 Equipment Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.2.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.3 SOFTWARE ASSESSMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 l

2.4 SYSTEM INTEGRATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 ,

2.4.1 Functional Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 2.4.2 Reliability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 2.4.3 Abnormal Conditions and Events . . . . . . . . . . . . . . . . . . . . . . . 2-6 2.4.4 Critical Characteristic Definition . . . . . . . . . . . . . . . . . . . . . . . . . 2-7 2.4.5 Guidance on Defining and Verifying Critical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 2.4.6 Failure Modes and Effects Analysis . . . . . . . . . . . . . . . . . . . . . . 2-9

' 3.0 ESSENTIAL FEATURES OF THE DESIGN, VERIFICATION AND VALI DATION PROC ESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .' 3-1 3.1 VERIFICATION PROCESS INTEGRATED WITH DESIG N PROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.2 MODU LAR DESIG N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.3 INCREMENTAL VERIFICATION ..............................3-1 3.4 DESIGN STRESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.5 VERIFICATION AND VALIDATION TEAM ,. . . . . . .. ..... . . . . . . . . . 3-1 3.6 LEVEL OF VERIFICATION AND VALIDATION . . . . . . . . . . . . . . . . . . . . 3-1 4.0 DOCUMENTS DEFINED BY THE DESIGN, VERIFICATION, AND VALI DATION PROC ESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4.1 SYSTEM DESIGN DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4.1.1 System Specification Document . . . . . . . . . . . . . . . . . . . . . . . . 4-1 l

4.1.1.1 System Functional Requirements Document . . . . . . . . . 4-1 4.1.1.2 System Block Diagrams . . . . . . . .. . . . . . . . . . . . . . . . 4-1 l

l Ma 31 1996 Revision 1 m 77w.wpf:1b-061296 i

e ii

• TABLE OF CONTENTS (Continued)

Section Title Page 4.1.2 System Design Specification . . . . . . . . . . . . . . . . . . . . . . . . .. 4-1 4.1.2.1 Composite Block Diagram . . . . . . . . . . . . . . . . . . . . . . 4-2 4.1.3 Hardware Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.1.4 Software Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.2 MODULE AND ASSEMBLY DESIGN DOCUMENTS . . . . . . . . . . . . . . . . 4-2 i 4.2.1 Hardware Design Specifications . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.2.2 Software Design Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.3 MODULE AND ASSEMBLY IMPLEMENTATION DOCUMENTS . . . . . . . . 4-3 4.3.1 Hardware implementation Specification . . . . . . . . . . . . . . . . . . . 4-3 4.3.1.1 Electrical Assembly Documents . . . . . . . . . . . . . . . . . . 4-3 4.3.1.2 Mechanical Assembly Documents . . . . . . . . . . . . . . . . 4-3 4.3.1.3 Wiring Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 4.3.1.4 Internal Connection Diagrams . . . . . . . . . . . . . . . . . . . 4-3 4.3.1.5 Intemal Power Distribution Diagrams . . . . . . . . . . . . . . 4-4 4.3.2 Software implementation Specifications . . . . . . . . . . . . . . . . . . . 4-4 4.3.2.1 Source Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4.3.2.2 Object Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4.3.3 Reliability Analysis Report ............................4-4 4.4 VERIFICATION AND VALIDATION PLAN . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4.4.1 Hardware Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4.4.2 Software Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 4.4.3 System Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 4.4.4 System Validation Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 4.5 MODULE AND ASSEMBLY VERIFICATION REPORTS AN D PROC EDU R ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 4.5.1 Hardware Verification Test Procedures . . . . . . . . . . . . . . . . . . . 4-5 4.5.2 Software Verification Test Procedures . . . . . . . . . . . . . . . . . . . . 4-6 4.5.3 Hardware Test Results Report . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 4.5.4 Software Test Results Report . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 l

i 4.6 SYSTEM INTEGRATION DESCRIPTION DOCUMENTS . . . . . . . . . . . . . 4-6 j 4.6.1 System implementation Specification . . . . . . . . . . . . . . . . . . . . . 4-6 l 4.6.1.1 System Electrical Assemblies . . . . . . . . . . . . . . . . . . . 4-6 4.6.1.2 System Mechanical Assemblies . . . . . . . . . . . . . . . . . . 4-7 4.6.1.3 System Wiring Diagrams . . . . . . . . . . . . . . . . . . . . . . . 4-7 4.6.1.4 System Intemal Connection Diagrams . . . . . . . . . . . . . 4-7 4.6.1.5 System Internal Power Distribution Diagrams . . . . . . . . 4-7 Ma 31 1996 Revision 1 m: 00d977w.wpf;1b 061296 l

e lii TABLE OF CONTENTS (Continued)

Section Title P_ age 4.7 SYSTEM VERIFICATION AND VALIDATION DOCUMENTS . . . . ..... 4-7 4.7.1 System Test Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 4.7.1.1 System Verification Procedures . . . . . . . . . . . . . . . . . . 4-7 4.7.1.2 System Validation Procedures . . . . . . . . . . . . . . . . . . . 4-7 4.7.2 Test Results Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 l 4.7.2.1 System Verification Test Results . . . . . . . . . . . . . . . . . 4-8 4.7.2.2 System Validation Test Results . . . . . . . . . . . . . . . . . . 4-8 4.8 PRODUCT DOCUMENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 4.8.1 System Interfacing Documents . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 4.8.1.1 Extemal Connection Diagrams . . . . . . . . . . . . . . . . . . 4-8 l 4.8.1.2 Signal Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 l 4.8.1.3 Extemal Power Requirements . . . . . . . . . . . . . . . . . . . 4-8 4.8.2 System Installation Documents . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 j 4.8.2.1 Field Separation Requirements . . . . . . . . . . . . . . . . . . 4-9 4.8.2.2 Environmental Requirements . . . . . . . . . . . . . . . . . . . . 4-9 4.8.3 Maintenance Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

! 4.8.3.1 Hardware Maintenance Manual . . . . . . . . . . . . . . . . . . 4-9

4.8.3.2 Software Maintenance Manual . . . . . . . . . . . . . . . . . . . 4-9 i

l 5.0 DOCUMENT CROSS-REFERENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 l 5.1 DOCUMENTS SPECIFIC TO HARDWARE . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.2 DOCUMENTS SPECIFIC TO SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . 5-1 I

! 5.3 SYSTEM LEVEL DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 6.0 R E FE R EN C E S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 l i

l l

4 i

i i

M 31 1996ood977w.wpf:1b-061296 Revision 1 l m:da

4 iv

• LIST OF FIGURES Floure Title Page a

Figure 1 Design, Verification, and Validation Process . . . . . . . . . . . . . . . . . . . . . . 1-5 Figure 2 System Development / Integration Process (SYSDlP) . . . . . . . . . . . . . . . . 1-6 Figure 3 Westinghouse AP600 Implementation /

Verification Process - Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Figure 4 Dependability Critical Characteristic Matrix for Digital Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 l

1 l

l I

i l

l l

I l

1 l

I l

Ma 1996 Revision 1 m: 3977w.wpf:1b-061296

11

1.0 INTRODUCTION

This document describes the design, verification and validation (DV&V) process that has been ,

l established to confirm that system functional requirements are properly and correctly Implemented in the instrumentation and control architecture of the AP600. This DV&V process will be applied throughout the instrumentation and control architecture in graduated  ;

degrees as required by the relationship of the specific system to safety needs. This docum'ent also describes the elements of the commercial grade item (CGI) dedication program which i provides for qualifying third party software / hardware elements and the use of previously j developed software.

Verification refers to the process of determining whether or not the product of each phase of the instrumentation and control system design process fulfills the requirements imposed by previous phases.

Validation refers to the process of testing and evaluating the integrated instrumentation and l

control system to confirm compliance with the functional, performance, and interface requirements used to design it.

The term, instrumentation and control system, as used in this document, refers to the integrated hardware and software design and equipment, conforming to the design that is provided to implement a subset of the functional requirements for a plant.

The DV&V process established by Westinghouse is an engineering approach used to aid in the development of high quality hardware, software, and system designs conforming to customer, regulatory, and Westinghouse requirements. The DV&V process was established as a means to direct the necessary activities in the design, implementation, verification, and validation of instrumentation and control systems. The DV&V procedure that implements this process defines the documentation item requirements, standards for the content and format of each document, and the interactions between the development activities and the verification and validation activities. An objective of the DV&V process is to verify the documents generated are correct, complete, and without ambiguity. The document titles, document definitions, and terms used are selected for consistency with industry standards, Westinghouse standards, and regulatory / licensing practices.

The software development process which is documented in this document is consistent with l I the following standards:

l . ANSI /IEEE ANS-7-4.3.2-1993 l . IEC 880-1986

! . IEEE 828-1990

! l l

Ma 31 1996 Revision 1 l m: 77w.wpf:1b-061296

4 1-2 i . IEEE 829-1983

• IEEE 830-1984

. IEEE 1012-1986

. IEEE 1028-1988 l

= IEEE 1042-1987 I 1

i. The DV&V process stresses a " Design for Verification" approach throughout the hardware design, software design, and system integration aspects of the project. This concept requires i

the following:

• The system design process is able to readily and immediately demonstrate that the system design completely and correctly incorporates the design requirements.

. The module hardware and software, assembly, and subsystem design methods provide features so that the resulting design of the module or assembly is immediately verifiable by independent review.

l

• The modules, assemblies, and subsystems contain sufficient test features to support verification testing and be able to be readily and immediately tested to verify that design requirements are met; and that the test results be immediately useable.

i

= The complete integrated system contains sufficient test features to support validation l testing and be able to be readily and immediately tested to verify that system l requirements are met; and that the test results be immediately useable.

l This integration of verification requirements directly into the design process in a top down fashion assures that the overall instrumentation and control system will readily satisfy the final system verification and validation testing programs by meeting the initial system design j requirements. l I

The individual steps within the design, verification, and validation process are controlled by a l I

senes of documents that define the individual activities, the inputs to these activities, and the outputs from these activities.

Figure 1 illustrates the DV&V process as it is established and has been used for the production of current projects. This figure shows the top-down approach used to incorporate the system design requirements and the functional requirements into the hardware and software design and production for the instrumentation and control system. These high level requirements are carried down to the level of hardware module design and production and software module design and production. After the hardware and software modules are tested j- and verified, the system is integrated, and tested. Finally the system undergoes the system l l

Ma 31 1996 Revision 1

, m: 77w.wpf;1b 061296 i

e 1-3 validation testing. Also shown on Figure 1 is the hardware and software configuration control process.

Figure 2 illustrates the DV&V process in another format and shows the interrelationships among the documents and processes controlled by the DV&V process.

Figure 3 expands on Figure 2 by showing a typical step within the process and illustrating the close coupling between the design activities and associated verification activities. The overall 3 process is decomposed into individual steps, with each step having defined input, output, a design or implementation activity, and a verification activity. .

When the overall system design implementation is complete, a validation activity is performed to verify that the basic system requirements have been met. This is illustrated in Figures 1,2, and 3.

The CGI dedication program established by Westinghouse is an engineering approach used to provide reasonable assurance that commercial-off-the-shelf (COTS) items properly and correctly implement the instrumentation and Control system functional requirements as specifiedi The CGI dedication process is integrated with, and is part of, the normal digital system design process. . Westinghouse applies the CGI dedication process to qualify third party hardware-and software elements as wall as previously developed Westinghouse software. Previously developed Westinghouse software may not have been developed using the full process

currently described; however, it can be qualified by using the commercial dedication process that takes credit for a systematic and controlled software design and development process coupled with years of test and field experience.

The following references provided the basis for the Westinghouse Commercial Grade item ,

i Dedication Program:

. ANSI /IEEE ANS-7-4.3.2-1993

• EPRI TR-102348

. EPRI NP-5652

. EPRI TR-102260.

. Regulatory precedence established by:

. Previous NRC safety evaluation reports on Class 1E systems

. NUREG 0800 Standard Review Plan proposed revisions i

- To impose verification and validation requirements on COTS hardware and software, the COTS vendor hardware and software design processes must be evaluated against the guidance provided in these standards. Exception (s) to development steps required by these Ma 31 1996- Revision 1  !

m. 77w.wpf:1b-061396

1-4 guidance documents may be acceptable depending on the safety system application and/or the presence of other compensating factors. For example, previous operating experience may be used if that experience meets the following criteria:

. Documentation of product assurance applied during the development phase

• Documentation to verify the use of good software engineering practices

. Documentation to verify significant error-free operating experience for the exact product version in similar applications

. Documentation to verify that an effective error-reporting mechanism has been in place so that experience data is valid r

I l

l l

l l

l l

l Ma 31 1996 Revision 1 m: 77w.wpf:1b-061296

I 1-5 DESIGN, VERIFICATION, AND VALIDATION PROCESS i

l. i l

6. _ . __ . _ . SYSTEu oESiGN REQUIREMENTS l._ . necTiONAL REQUIREMENTS . _ _ _ _ _ _:

j l t If 1f ,

CA 4~~~~~~~~~~~~~~~~

I I. i, R R

' TROUBLE TROUBLE SYSTEM REPORT l SYSTEM HARDWARE l I

{*

l DESIGN SPECIFICATION SPECIFICATION g

i e

g l L_._ __._! 1r l L T

, i , ,

F* HARDWARE DESIGN SOFTWARE DESIGN 4J e 8 I'- I a,

i 1 i I

l

' 1

. I jf jf I g i i i

l i e 4 8 HARDWARE SOFTWARE i l

8 IMPLEMENTATION IMPLEMENTATION 1 I

. 4) 1' I  :

lf f ,

e

• I HARDWARE SOFTWARE 8 e

l 8--< VERIFCATION VERIFICATION -8 9 TESr TEST i i

l i

1

. SY M M l INTEGRATION  :

l i___.__._.__._.__.__._. ,,,,,,, j

(

REPORT g l

- SYSTEM

@ VERIFICATION .________________wI l ,

I.__ ____.._..___.__._.____. y i

PROBLEM e SYSTEM REPORT a INDCATES INDEPENDENT REVIEW ,,

VALIDATION lf SYSTEM COMPLETE FILE: VPN.1.DRW l JJB 5/1141 Figure 1 Design, Verification, and Validation Process Ma 31 1996 Revision 1 m: 77W.wpt1b-061296 i

=

SYSTEM m, REOUlFIEMENTSm - ,m VERIFICAT4 m DEFINITON PHASE m w

m DEVELOPMENT PHASE 1'o1*

? Es N Erze n ag99 =

hfiP

- /pw/g/lj"g!SYSTEM DEVELO.

REQUIREMENTS ,

1i A ll REQUIREMENTS DOCUMENTS:

ll SYSTEM SYSTEM sl i DESIGN DESIGN l

- PMD ANDrOR SmATEGC a

il VERIFICATION g!]

PLANNIW ll ll_____

g VERIFICATON p

REQUIREMENTS , l DESIGN DOCUMENTS:

, 1 l DOCUMENTS: MODULE AND MODULE AND . .

DOCUMENTS g - SYSTEM DESIGN lgI -SYSTEM SUBSYSTEM DESIGN rSUBSYSTEM

-Eb" DESIGN l

8l SPECIFCATON e SYSTEM DESIGN el 8

e SYSTEM BLOCK ll VERIFICATION INSPECTION - {l VERIFICATON REQUIREMENT 8

' DIAGRAM AND GENERAL ll RESULTS DESIGN DOCUMENTS: l VERIFICATION e QUALITY ASSURANCE ll DESCRIPTON ll - HARDWARE DESIGN SPECIFCATION DOCUMENTS:

l g HARDWARE MODULE AND SUBSYSTEM IMPLEMENTAq REQUIREMENTS g l e COMPOSITE jl VERIFICATION e FUNCTIONAL tel BLOCK DIAGRAMS ll - SOFTWARE DESIGN SPECIFICATION lll lNSPECTION IMPLEMENTATOf REQUIREMENTS 8 AND 8 HARDWARE ll l l RESULTS SOF1 WARE DESIGN DIAGRAMS ll DESIGN ll VERIFICATON DOCUMENTS:

e MAN-MACHINE INTERFACE

,l REQUIREMENTS SOFTWARE ll ll INSPECTIOes RESULTS

- ELECTRCAt.

ASSEMBLIES a

REQUIREMENTS I l DESIGN lg l MECHANICAL i

e FLUID SYSTEMS 8 l REQUIREMENTS ll lll ASSEMBLIES AND BOP REQUIREMENTS '

3 ll l CABLES ll ll l

- CUBCLES l l - MODULE CODE l

al SUBSYSTEM CO i

8 ll 1l l

=

ll ll g CONFIGURATOt DATA ll II Il ll ll !l l 1_ _ _ _ _ I l I

li i

i

, - _ _ ____ _ _ _ _ _ _il g

• VERIFCATON REQUIRED FOR SAFETY SYSTEMS CNLY I..........--...........----............-------------...

May 31 1996 m:Wp600'd977w-1.wpf:1b-061296 w w

1 c . .

l l

1-6

)

_A,-

I L l TEST PHASE 3 MENT / INTEGRATION PROCESS i SYSDIPS)

N l

l I

p ON FIGURE 1.1 OF DOCUMENT C&PGSTD-001, REV 5, 5/10/90) l i

? DESIGN

~MODULE

~ ~AND~ .~

~ ~

MODULE AND [ - - VERIFICATON SUBSYSTEM SUBSYSTEM I N VERIFICATON l IMPLEMENTATON VERIFICATON l ~l ~ ~ ~ ~ ~

TESTS l

- - - - % VAUDATON

~~~'~

I lI v cA Ol D V _____ _____

l DOCUMENTS: ll SUBSYSTEM TEST SYSTEM SYSTEM SYSTEM t VERIFICATON INTEGRATON VERIFICATION VALIDATION l 1

HARDWARE ll DOCUMENTS: TEST TESTS l i l VERIFICATON [ ,_ _ _ _a , ,_ _ _ _I INSPECTION HARDWARE e l RESULTS VERIFICATION SYSTEM l SYSTEM 8 SYSTEM ll TEST INTEGRATON VERIFICATON TEST 8 VAllDATON l - SOFTWARE ll PROCEDURES DRAWINGS: VERIFICATION t TEST YERIFICATON '

l DOCUMENTS: , DOCUMENTS INSPECTION ll - SOFTWARE - SYSTEM RESULTS VERIFICATON CONFIOURATON -SYSTEM l

i l l - SYSTEM TEST VERIFICATION I VALIDATON CADINET l l ll PROCEDURES CONFIGURATONS TEST PROCEDURES I

I TEST PROCEDURES

. J. F* -

l ll - HARDWARE TEST I L

E RESULTS REPORT CARD CHASSIS SYSTEM ' SYSTEM l [

ll CONFIGURATIONS VERIFICATON ', VALIDATON SOFTWARE TEST TEST RESULTS TEST l ,

li RESULTS REPORT - PC BOARD MANUAL RESULTS gSO Avanable on l l CONFIGURATIONS l

- RELIABILITY t

Aperture Card l PROMS  ! ANALYSIS e ll l ll - WIREUSTS '

l I l1 - TERMINATON l

-l___ _pl--___ ASSIGNMENTS l g i

i FILE: SYSDIP.DRW

__________________________________________________i ,, _

Figure 2 System Development / Integration Process (SYSDIP)

Revision 1 wwxwCI .

17 WESTINGHOUSE AP600 IMPLEMENTATIONNERIFICATION PROCESS -

SUMMARY

ONE STEP OF MANY b

/ \

INPUTS

• OUTPUTS =

JL il TROUBLE REPORT VERIFICATION ACTIVITY TROUBLE REPORT l PROBLEM REPORT PROBLEM REPORT I FINAL BASIC REQUIREMENTS VAllDATION DESIGN ACTIVITY e

gvw 4mnw Figure 3 Westinghouse AP600 Implementation /

Verification Process - Summary

"*viSi a '

$A.'4%--

2-1 2.0 ELEMENTS OF THE COMMERCIAL GRADE ITEM DEDICATION I PROGRAM 2.1 VENDOR ASSESSMENT 2.1.1 Vendor Design, Verification and Validation Process System design and application development shall proceed in a traceable, planned, and orderly manner, in accordance with the phases identified below. It is also necessary that planned verification and validation activities occur at each phase of the system design life cycle model. j The DV&V process activities shall ensure the following: l l

. The hardware and software design adequately and correctly performs all intended functions; and 4

. The hardware and software design does not perform any unintended function (for  !

example, contact output inhibit or epurious actuation) that either by itself or in combination with other functions can degrade the entire system.

The phases expected to be present in a quality and comprehensive system development project are:

1. Conceptual / Planning Phase: The period in which user needs are described and evaluated.

2. Requirements Phase: The stage in which the requirements of the system architecture (functionality, performance, design constraints, attributes, testability, extemal interfaces,

, and the like) are specified, documented, and reviewed.

3. Design Phase: The period in which the hardware is designed, software algorithms are developed, validated, documented, and reviewed in accordance with previously established requirements.

4. Implementation Phase: The period in which the design is translated into hardware and software, and the implemented hardware and software is reviewed and tested to identify and correct errors.

I

5. Integration and Test Phase: The stage during which the hardware and software are 4 integrated together as a system and tested. Integration testing is performed in accordance with test procedures, and results are analyzed to ensure that the hardware Ma 1996 Revision 1 m 977w.wpf;1tHM1296

2-2

• and software components function correctly together and that the system fully implements its requirements.

6. Installation and Checkout Phase: The period during which tests are performed to verify all software, hardware, and data packages are properly installed and operating.

7. Operations and Maintenance Phase: The period after initial system development, verification, and validation are complete and the system has been approved for operational use. Activity at this point consists of corrective maintenance and code enhancements. All proposed hardware and software changes should be evaluated to determine overall effects on the system and to ensure that adverse effects have not been introduced. All software modifications are to be performed in accordance with the originally approved development process.

8. Retirement Phase: That period after which support for the product is terminated. At this point, efforts shall be undertaken to ensure that all appropriate records have been retained for the life of the AP600 Nuclear Power Generating Station.

2.1.2 Software Quality Assurance (SOA) Plan COTS software shall be designed and controlled according to an SQA Plan in accordance ,

with paragraph 5.3.1 of ANSl/IEEE ANS-7-4.3.2-1993. The essential elements of a quality j l SQA Plan are:

. Traceable, planned, orderly development

. Controlled software design process l

= Procedures for design, development, review, testing ,

l . Independent review process )

. In-depth testing at unit and module levels, or code reviews; all testing and reviews and documented

. Random testing l

= Problem reporting and resolution tracking l

= Integrated hardware and software Acceptance Test Plan l

. Verification of intermediate phases

. Validation process ,

. Documentation of organizational structure for review of test results 4

i 1

1 Revision 1 NhDwptib-os12ss l l

1

2-3 2.1.3 Vendor Compliance Report A formal review shall be conducted of the COTS equipment vendor to verify that the design process for the hardware and resident library of software modules is consistent with the system life cycle development phases previously discussed.

A summary of the observations and conclusions which result from this review process shall be documented in a vendor compliance report.

2.2 HARDWARE ASSESSMENT COTS hardware shall be dedicated in accordance with WCAP-12885, Method Vil-2. The Westinghouse dedication program is designed to provide objective evidence and reasonable  !

assurance that items purchased by Westinghouse and dedicated for ultimate safety-related .

use conform to key procurement requirements and Appendix B criteria, and will be suitable for I their intended function.

l J

2.2.1 Equipment Qualification Equipment qualification will be in accordance with paragraph 5.4 of ANSI /IEEE ANS-7-4.3.2-1993.

The equipment will be qualified for the following events and conditions:

l

. Environmental: temperature and humidity l

. Seismic

. EMI/RFI susceptibility and noise propagation

. Noise

. Fault  ;

. Surge withstand capability

. Radiation

- Independence i

2.2.2 Documentation l

The following documentation will be available to support the hardware assessment and l

commercial dedication:

I f . Functional block diagrams

.- Hardware block diagrams and interface drawings

. Boundary drawings:

Protection / control system interfaces Protection divisions 6 w f:1b-061296 -

l

2-4 a Power Sources and Interactions:

Electrical voltage and frequency Power surges interface with power sources isolation at Interfaces .

l

• Licensing and safety evaluations

! . Industry codes, standards, requirements, criteria, specifications, calculations

. Test reports (factory and site acceptance)

.. Operational and maintenance procedures

. Periodic test procedures a Self-diagnostic data'

!

• Failure modes and effects analysis 2.3 SOFTWARE ASSESSMENT The software portion of a COTS-equipment-based system consists of three elements:

L

1. The operating system software L 2. The resident library software

3. The application software.

l The wide commercial usage of operating system software must have been in a similar - l application with a similar range of operation. The resident library code must have been - l developed using an SOA process and the application code must have been developed under  :

the V&V process.

To assess the acceptability of the software design, an SQA Plan identifies processes and i procedures that demonstrate the following:

• The software is in accordance with the functional design, and that the implementation process will result in reliable software l

l

• An adequate program is in place to assure that the reliability of the software is l maintained for the entire software life cycle, including revisions to permanent software

~ (operating system and resident library software) and the application software f in order to perform the software assessment, the user evaluates the following: j i

' i

1. Design, development, and operational history of vendor software (operating system and resident library) l 1 1

l. Ma 31 1996 Revision 1 m: 77w.wpf 1b-061296 l

_ _ _ _ _ _ _ _ _ _ _ _ . . . _ _ _ - _ u

. = - .

2-5 This is accomplished by review of the following:

- Vendor design and software development activities

. Scope and results of static and dynamic software tests

. Acceptance tests performed and their results

. Documentation of all software modifications since release

. Programmable read-only memory (PROM) burn-in process and procedures to ensure that PROM is correct

2. Procedures and methodologies to ensure that hardware and software control blocks are functionally equivalent to the system design basis.

This is accomplished by review of the following:

. System functional specifications and derivation of control block configuration

. Procedures and methodologies to ensure that control block configuration implements control logic as specified l

. User-configurable software management program

. System test results, errors / failures, method of detection, and method of correction

3. Design, verification and validation process to control user configurable software elements (application software).

This is accomplished by review o' the following:

. Verification procedures

. Verification results during developmint, including characterization of errors

. Validation results ,

, i l

l 1

l May 31 1996 Revision 1 l m:\np600\E977w.wpf:1b-061296 I

2-6 a

= Independence of verification and validation activities

- Change control procedures All tools, techniques, and procedures used for the verification and validation functions shall be documented and retained within a controlled library. This is particularly important because the efficiency of the entire process is greatly increased through the use of specially developed

)'

custom computer tools to process program source code and documentation. These tools and their associated documentation reside within the library.

2.4 SYSTEM INTEGRATION 2.4.1 Functional Compliance Assessment of functional compliance relative to system design basis will be completed by performing the following actions:

. Assessment of vendor design, verification and validation process (requirements, specs, and the like.)

. Assessment of users development of the system design with respect to the design basis.

• Assesstr ' 6 user and vendor pmcedures and methodologies for transformation of functione, requirements to software configuration.

. Assessment of the configuration management process Maintenance i Firmware revisions that occur after dedication l 10CFR21 Reporting 2.4.2 Reliability and Availability The analysis of reliability (mean time to failure or mean time between failures) and availability shall have adequate (supportable) data and sufficient margin to provide reasonable assurance of meeting the reliability requirements for the inteaded application.

2.4.3 Abnormal Conditions and Events Computer development requires the identification of abnormal conditions and events (ACES) that have the potential for defeating the safety function. ACES include extemal events as well

{

Revision 1 g3g199

e (

r *-

2-7 r 4

as conditions intemal to the computer hardware or software. ACES shall be addressed  !

consistent with the guidance of Annex Fot ANSI /IEEE ANS-7-4.3.2-1993.  !

l f 4

2.4.4 L Critical Characteristic Definition 3

4 Critical characteristic definition is accomplished with the following actions:  ;

i  ;

j . Identify methods and acceptance criteria for verifying the critical characteristics, such as during manufacturing process (hold points), receipt inspection, dedication process j or post-installation testing. l l

. Establish verifiable, documented traceability of complex commercial grade items to i their original equipment manufacturers in those cases where the dedication program l cannot verify the critical characteristics.  ;

' l

I I . Vendor surveillance

Some commercial grade items cannot be fully dedicated once j received on site. Certain items are manufactured using special processes, such as

soldering, welding, conformal coating, and the like. Dedication testing of these items L as finished products would destroy them. For these items, the user may need to conduct vendor surveillances or witness certain activities during the manufacturing

process.

) Assurance will be provided for the suitability of all parts, materials, and services for their intended safety-related applications, that is, there will be assurance that the item will perform its intended safety function when required. The user is responsible for identifying the important design, material, hardware and software performance characteristics for eech part, material, service, assembly, and the like, intended for safety-related applications, ests blishing acceptance criteria, and providing reasonable assurance of the conformance of items to these '

criteria. The critical characteristics for an item may vary from application to application depending on the design and performance requirements unique to each application.

Different approaches for the verification of the critical characteristics may ba used depending

. on the compiexity of the item. In many cases, critical characteristics may be verified during  ;

receipt inspection testing. However, for complex items with intemal parts that receive special processing during manufacturing, the user may need to conduct a source verification of the manufacturer during production to verify the critical characteristics identified as necessary for the item to perform its safety function. When these methods cannot verify the critical ,

characteristics related to special processes and tests, certification by the original equipment i manufacturer may be an acceptable attemative provided that documented, verihed tracea.bility to the original eq'uipment manufacturer has been established and the user has verified by audit or survey that the original equipment manufacturer has implemented adequate quality  !

controls for the activity being certified. j Ma 31 1996 Revision 1

. m: 77w.wpf;1b-061296 l

l

. - - _ . _ . - . _ _ _ - - _ _ _ _ _ _ - _ _ - _ - . . _ _ _ - - - - - , -,-.,-L~ - - - - - . ~ n,- c , .e

2-8 a For items with critical characteristics that can be verified for the most severe or limiting plant application, the user can identify and verify each item's critical characteristics to qualify that item for all possible plant applications. For complex items that would be purchased for specific plant applications, it may be appropriate to address the acceptance criteria for each item individually. Engineering and procurement involvement is important in either method because the technical evaluation will identify the critical characteristics, acceptance criteria, and the methods to be used for verification.

2.4.5 Guidance on Defining and Verifying Critical Characteristics Critical characteristics are those important design, material, and performance characteristics of a commercial grade item that, once verified, will provide reasonable assurance that the item will perform its intended function. Identification of the critical characteristics for a commercial grade item is a key element in the dedication process.

In EPRI TR-106439, the critical characteristic of dependability becomes important when dedicating digital equipment, including software. It is critical to address the need for the commercial item to perform reliably and dependably over its service life, including assessment of the quality and integrity of the software provided with the item. It is well established that for software-based systems, quality is best achieved by building it in, following a life cycle approach from requirements through implementation, with verification and validation steps and appropriate documentation along the way. However, a commercial product can be judged to have sufficient quality, even if its development process lacked some of the rigorous steps of modem software engineering and/or some formal documentation. The dependability category captures those critical characteristics that must be evaluated to form an appropriate judgment regarding built-in quality of a software-based device. It also includes characteristics related to problem reporting and configuration control. Verification of these characteristics typically involves a survey of the vendor's processes and review of the vendor performance record and product operating history. Source inspections may also be used.

The critical chsracteristics in the dependability category, including the built-in quality characteristic, are somewhat different from those in the other categories because they are less tangible and harder to measure than, for example, a part number of a physical dimension. Reaching an adequate level of assurance of the quality of a commercial grade item typically involves making a judgment based on a combination of operating history, product development process, documentation, testing, and other factors as noted in Figure 4.

Revision 1 M&hESS#-m L -

2-9 2.4.6 Failure Modes and Effects Analysis A failure modes and effects analysis (FMEA) will be performed in accordance with the following elements:

. Used to refine critical characteristics

. Detectability of failures

. Recovery

. Special failure modes (system halt, timing errors, instability)

. Frequency and severity of transient

. Software failures due to design errors (common mode software failures) defense-in-depth

- -diversity (reference Annex B of ANSI /IEEE ANS-7-4.3.2-1993)

- credit for self-diagnostics

- hardware random failures due to aging / stress / components m N d9 w f;1b-061396

~ ~

~

N I

Critical Characteristics Acceptance Critoria*

for Acceptance Dependability Criteria for reliabelsty and mamtainability derive from the Reliabil requirements of the intended application (s). Specific criteria may historyi Reliability and maintainability related to the required be established such as numerical criteria for reliatwirty or availabdity functionality of required funchons, or maintainability criteria including software. Review Built-in quality including:'

D@

Basic criterion for built-in quality is to ensure quality is equivalent to . Quail

• Quality of desagn that of a device developed under a 10 CFR 50 Appendix B .V&VI

. QuaHty of manufacture program. Judgment of equivalent quakty is based on a

. Failure management combinabon of: Design

. Compahtuhty with human operators, maintamers . Testing by the vendor or dedcator use ofi

. Design and desagn review pmaa=, including software Efe Conhguration of control and traceabuity of:* cycle, V&V, etc. Failure

. Hardware . Design documentabon item its e Software . Configuration management

. Firmware (aspects of both hardware and software . QA program and prachces Review configuration control) . Software requirements definition and requirements traceability . Docui

. Consideration of faHure modes and ACES in design and . Suffic Problem reporting verificahon . Succq

. Qualificahons and exponence of personnelinvolved in design includ and verifcahon activities . Relev

. Product operating history functi Minimum criterion for configuration control and traceabihty is that Configu these be sufficient to support use of operating history data and to practce ensure the item delivered can be traced back to the documents reviewed as part of acceptance Addshonal criteria may apply if the Probierr dedcator wishes to procure more of the same item in the future. Assess contract As a minimum, problem reporting must be sufficient to support use of product operating history and to allow dedcator to carry out Assess 10 CFR 21 responsibilities. Specific criteria may be established (e.g., coverage, timeliness, reporting to the right people).

• Note that these are examples only, and they are not all-inclusive. The dedicator must determine which activities are appropriate for eaci Ma 31 1996 m: 77w-1.wpf.1b-061296 u.- 'e

1 l

l 2-10  !

l Methods of Verification

• Application of Esthods*

ty: Review vendor reliability calculations. Review operating The number and extent of verification achvities required depend fata. Review and assess deign. Perform reliability analysis. on the complexity and safety signif'cance cf the device.

Supplemental activities may be required such as additional of vendor processes and documentation: testing, verifications or analyses, and documentation.

n, development, and verification processes k assurance program and practices Many of the required characteristics can be verified once for a ,

>rogram and practices given type or model of equipment and the verification would not

{

have to be repeated for each application of that device in the l

'eviews - trchitecture review, code reviews, walkthroughs, plant. This requires verification that the vendor's configuration i palytical techniques, etc. management and quality control practices assure that the same item (with the same verified characteristics) is received with each j inalysis, at the system level and of the commercial grade new procurement. Also, if the device is to be applied in a more  ;

af. critical application, additional verification activities may be needed.

of product operating history:

nented (records, traceable) ent (units, y ars in service) )

J ssful (irr:r tracking shows good performance and device  !

ng software is stable) ant (same or similar hardware / software configuration, ^

ins used, operated similarly, etc.) MNSTEC ation and control: Review vendor CM program and APERTURE

5. Examine actual practices, records. CARD l reporting: Review vendor procedures and practices.

Also AvaHable on i prformanca record with previous customers. Enter int ual agreement. Aperture Card Tiaintainability of dedication.

application.

Figure 4 j Dependability Critical Characteristic Matrix for Digital Equipment l l

Revision 1 Mo6ztoozl-02 - -

3-1 3.0 ESSENTIAL FEATURES OF THE DESIGN, VERIFICATION AND VALIDATION PROCESS 3.1 VERIFICATION PROCESS INTEGRATED WITH DESIGN PROCESS The design process and the verification and validation processes are integrated into the overall DV&V process. Hardware and software that conform to the DV&V process have incorporated into their design specialized features that enable, enhance, and support the verification process.

3.2 MODULAR DESIGN An implicit feature of the DV&V process is the philosophy of modular design for both the hardware and software used to implement the instrumentation and control system design.

This provides readily available, pre-verified parts for use in assembling the system.

3.3 INCREMENTAL VERIFICATION The DV&V process is invoked on the smallest hardware and software entities for which functional specifications can be defined and established. Verification and validation of as-semblies, composed of these entities, becomes a test of proper interfacing and usage of already verified and validated parts.

3.4 DESIGN STRESSING Each module and assembly is tested over its possible (design) range of use, providing a higher level of assurance than is possible at the integrated system level.

3.5 VERIFICATION AND VALIDATION TEAM The verification and validation process is performed by independent reviewers who meet the requirements and have the responsibilities defined in the published, QA approved, division and department procedures documents.

3.6 LEVEL OF VERIFICATION AND VALIDATION The level of verification and validation performed on individual modules, assemblies, subsystems, and complete systems is commensurate with the safety classification of the system and intendttd use in the plant. This level is established for each module, assembly, and subsystem as part of the system design process, based on the system design requirements. The results of this verification and validation level identification process are an integral part of the system design documents.

Mg1g Revision 1

4-1 4.0 DOCUMENTS DEFINED BY THE DESIGN, VERIFICATION, AND VALIDATION PROCESS The documents described in this section are controlled by, and are essential parts of, the design, verification, and validation process.

4.1 SYSTEM DESIGN DOCUMENTS 4.1.1 System Specification Document The system specification document, as defined by program operating procedure AP-2.1 in WCAP-12601, establishes the basis for the system design. This document addresses the applicable codes, standards, and functional requirements and acts as a design definition document. This document establishes applicability and requirements to meet single failure, diversity, electrical separation, and other applicable criteria, defines environmental and power source envelopes, establishes requirements related to access control', redundancy, independence, identification, and test capability. It defines requirements on system inputs and outputs, system safety classification, reliability, and establishes quality assurance, verification and validation, and environmental qualification requirements.

4.1.1.1 System Functional Requirements Document The system functional requirements document, in conjunction with the functional diagrams, defines the performance requirements for the plant protection and control functions of the plant Instrumentation and control system. This document identifies the plant parameters to be monitored, the protection and control algorithms to be performed, and operator interfaces, such as alarms and indications. The functional requirements document also specifies instrument and channel ranges, accuracy requirements, and time response requirements.

4.1.1.2 System Block Diagrams The system block diagrams represent a top level depiction of the system architecture and its interconnections, and provide a description of the system architecture.

4.1.2 System Design Specification The system design specification document provides the detailed specifications for the system design and integration of the hardware and software modules, and assemblies to meet the

' Access control includes requirements for the type of memory (such as PROM, EEPROM, etc.) to be used for object code and various types of system data.

mh w f:1b-061296

4-2 '4 system design requirements. It describes system structure, system operations, module and assembly interface protocols, and detailed system performance characteristics.

4.1.2.1 Composite Block Diagram These drawings provide a functional depiction of the instrumentation and control system block diagram and related information.

4.1.3 Hardware Design Requirements The hardware design requirements document defines requirements for the system hardware.

This document includes general as well as specific system and technical requirements, environmental requirements, and lists applicable reference documents and pertinent supplier information for individual hardware modules.

4.1.4 Software Design Requirements The software design requirements document defines requirements for the system software.

This document lists the functions, performance, design constraints, and attributes of the overall system software and external interfaces. The software requirements in this document are defined such that they are capable of being verified by a prescribed method such as inspection, analysis, demonstration, or test. l 4.2 MODULE AND ASSEMBLY DESIGN DOCUMENTS 4.2.1 Hardware Design Specifications s The hardware design specification documents provide the details for the hardware design at the module level required to meet design requirements. These documents define the physical structure, interface constraints, ratings, characteristics, functional operation, module inputs / outputs, power requirements, and special features of the instrumentation and control system hardware.

4.2.2 Software Design Specifications The software design specification documents provide the details for the software design at the module level and assembly level to meet the software design requirements. These documents define the software language, logical structure, variable names, information flow, logical processing steps, and data structure of the individual software programs. They also l

77w .1b-061296

l o' 4-3 1

describe the functions performed, support software, storage and execution limitations, inter-face constraints,- error conditions, error detection, error response actions, and details of the software operation in the hardware environment.

4.3 MODULE AND ASSEMBLY IMPLEMENTATION DOCUMENTS 4.3.1 Hardware implementation Specification

- The hardware implementation specification document presents the description of the hardware design as it is implemented, also known as the as-built documentation. This document

- includes a manufacturing standard drawing package for each hardware module in the

- instrumentation and control system, in addition, other implementation definition documents, which were used as stand-alone documents are compiled into this document.

4.3.1.1 Electrical Assembly Documents The electrical assembly documents describe the electrical fabrication and assembly of individual modules and assemblies that comprise the instrumentation and control system.

These documents typically will include such items as a bill of materials, process specifications,

- component assembly drawings, artwork, and schematic diagrams for individual electrical assemblies.

)

4.3.1.2 Mechanical Assembly Documents  ;

The' mechanical assembly documents describe the mechanical layout, fabrication, and l assembly of the cabinets and assemblies that comprise the instrumentation and control system. These documents define such items as cabinet layout, card crate assemblies, printed circuit card placement, intemal cable assemblies, and wiring details. These documents typically will include such items as a bill of materials, artwork, and assembly requirements.

4.3.1.3 Wiring Diagrams The wiring diagrams present the point-to-point interconnections within individual assemblies in the instrumentation and control system. Wiring diagrams typically include such items as wire lists, wire specifications, and cable routing requirements.

4.3.1.4 Internal. Connection Diagrams -

4 The intemal connection diagrams contain the intra-cabinet wire and cable routing and identification within individual assemblies in an instrumentation and control system.

Revision 1 Mgig

4-4 4 4.3.1.5 Internal Power Distribution Diagrams The intemal power distribution diagrams describe the power distribution design within the cabinets that comprise the instrumentation and control system. These diagrams typically include such items as intemal wiring requirements, routing requirements, wire specifications, bus requirements, grounding requirements, and labeling and identification requirements.

4.3.2 Software implementation Specifications The software implementation specification presents the description of the software design as it is implemented, also known as the as-built documentation. This document includes the source program listings and object programs.

4.3.2.1 Source Program The source program is the first part of the implementation of the software design. The source program is written by a software designer or programmer to perform the functions specified by the software design specification. The source program contains the necessary comments, functional diagrams, extemal references, and intemal module descriptions for consistent and self explanatory documentation.

4.3.2.2 Object Code The object code is the second part of the implementation of the software design. The object code is generated from the source program and installed in microprocessor subsystem memory to perform the functions specified by the software design specification.

4.3.3 Reliability Analysis Report The reliability analysis report provides an analysis of the systems availability based on availability analyses of the specific modules and subassemblies used for the instrumentation and control system. This report describes the assumptions, calculation methodology, and results of the analysis.

4.4 VERIFICATION AND VALIDATION PLAN 4.4.1 Hardware Verification Plan The hardware verification plan defines the process to demonstrate that the hardware design requirements and hardware design specifications are met. This document defines what hardware is required to be verified and the extent of the verification methods. This document i

m \E9 w t1b-061396

o

'k 4-5 l includes such items as hardware test methods, categorization requirements, test methods, inspection methods, checklists, and administrative responsibilities.

4.4.2 Software Verification Plan The software verification plan defines the process to demonstrate that the software de. sign requirements and software design specifications are met. This document defines what (

software is required to be verified and the extent of the verification methods. This document includes such items as the test levC.; the software has been divided into, error codes, applicable inspection methods, checklists, guidelines, administrative responsibilities, test methods, and inspection methods.

4.4.3 System Verification Plan The system verification plan defines the process for system verification. This document provides the basis that establishes that the system conforms to the system design specifications. The system verification plan also establishes that the assemblies are properly interfaced and that the instrumentation and control system interfaces properly with the extemal environment. The plan also typically establishes that the interfaces between the functional units are correct and that the data flow and control flow between different software modules works correctly.

4.4.4 System Validation Plan The system validation plan identifies the system design documentation and instrumentation that is to be validated and a series of comprehensive system functional and transient test cases, simulating normal and abnormal system operation conditions. The validation plan typically contains validation principles, standards, methods, administrative responsibilities, checklists, flow diagrams, and other performance evaluation tools.

4.5 MODULE AND ASSEMBLY VERIFICATION REPORTS AND PROCEDURES )

4.5.1 - Hardware Verification Test Procedures The hardware verification test procedures define the testing program and process for individual functional parts, modules, subassemblies, and assemblies within the instrumentation l and control system. These documents define the tests to be performed, the test methodology, the test environment, expected results, and acceptance criteria. Each test procedure covers a specific functional item or module. Typical tests performed are voltage limits, throughput, response times, and environmental exposure.

k b9 w tib-061296

4 4.5.2 Software Verification Test Procedures The software verification test procedures define the testing program and process for individual software functional units, modules, and assemblies within the instrumentation and control system. These documents define the tests to be performed, the test methodology, the test environment, expected results, and acceptance criteria. The documents also cover details of input generation, and how the expected results and acceptance criteria are determined.

4.5.3 Hardware Test Results Report The hardware test results report presents a summary of the hardware verification testing results, any errors found, and their resolution. This document, in conjunction with the hardware design specification, and hardware verification test procedure contains sufficient information to enable a third party to repeat hardware tests and understand the results.

4.5.4 Software Test Results Report The software test results report presents a summary of the software verification testing results, any errors found, and their resolution. This document, in conjunction with the software design specification, and software verification test procedure contains sufficient information to enable a third party to repeat software tests and understand the results.

4.6 SYSTEM INTEGRATION DESCRIPTION DOCUMENTS 4.6.1 System implementation Specification This document presents the description of the system design as it is implemented, also known as the as-built documentation. This document includes a manufacturing standard drawing package for each instrumentation and control system. In addition, other implementation definition documents, which were used as stand-alone documents are compiled into this document.

4.6.1.1 System Electrical Assemblies These documents describe the electrical fabrication and assembly of the overall instrumentation and control system. These documents include information on such items as system connector panels, fans and blowers, circuit breakers, grounding systems, power ,

supplies, and test panels, and typically include assembly drawings and schematic diagrams. l l

l '

\

l mNN0b9 w f;1b461396

4-7 4.6.1.2 System Mechanical Assemblies These documents describe the layout and assembly of the overall instrumentation and control system. These documents include information on such items as system configuration, cabinet layout, printed circuit card placement, intemal cable assemblies, and wiring details, and typically include assembly requirements.

4.6.1.3 System Wiring Diagrams The system wiring diagrams present the point-to-point interconnections between individual assemblies in the instrumentation and control system. These documents define such items as wirelists, wire specifications, and cable routing and tie down requirements.

4.6.1.4 System internal Connection Diagrams The intemal connection diagrams contain the intra-cabinet wire and cable routing and identification between individual assemblies in an instrumentation and control system.

4.6.1.5 System Internal Power Distribution Diagrams The system internal power distribution diagrams describe the power distribution design between the cabinets that comprise the instrumentation and control system. These documents include such items as intemal power wiring requirements, wire specifications, grounding requirements, and labeling and identification requirements.

4.7 SYSTEM VERIFICATION AND VALIDATION DOCUMENTS 4.7.1 System Test Procedures 4.7.1.1 System Verification Procedures The system verification test procedures define the testing program and process for integrated system verification test. These documents define the tests to be performed, test methods, and acceptance criteria to achieve system verification. The tests are typically overlapping static and dynamic tests which progress from detailed performance checks of modules and assemblies to more expanded performance checks of the overall instrumentation and control system.

4.7.1.2 System Validation Procedures The system validation test procedures define the testing program and process for integrated system validation test. These documents detail the stages and progression to functionally test May 31 1996 Revision 1 m.W\E977w.wpf:1b-0612%

4-8 '

the entire instrumentation and control system. These documents define the tests cases and acceptance criteria to achieve system functional validation. The test cases simulate real life plant conditions and typically include such tests as static and dynamic calibration and operational tests, functional logic tests, and signal interface tests.

4.7.2 Test Results Manual 4.7.2.1 System Verification Test Results The system verification test results are the performance test results compiled during integrated system verification tests. These documents include such items as response times, accuracy, power margins, noise levels, and overload and recovery characteristics.

4.7.2.2 System Validation Test Results The system validation test results are the performance test results compiled during integrated system validation tests. These documents include such items as extemal stimulus / output results, interaction between assemblies, and information transport.

4;8 PRODUCT DOCUMENTATION 4.8.1 System interfacing Documents 4.8.1.1 External Connection Diagrams The extemal connection diagrams define the interfaces required for the instrumentation and control system to extemal systems. These drawings include such items as cabinet termination points, system cable routing, and cable type.

4.8.1.2 Signal interface List The signal interface list defines the signal paths configured for the instrumentation and control system. These are signals from sensors to cabinets, actuation and trip signals from cabinets, l l

display data, plant status, and system data interfaces.

4.8.1.3 External Power Requirements The extemal power requirements document defines the electrical power requirements for the instrumentation and control system. This document includes voltage, frequency, and capacity requirements for the instrumentation and control system.

Mgig Revision 1

• 4-9 4.8.2 System Installation Documents 4.8.2.1 Field Separation Requirements The field separation requirements document defines the physical and electrical separation requirements for installation of the instrumentation and control system. This document specifies such items as wiring separation groups, equipment location, and any physical barriers required.

4.8.2.2 Environmental Requirements The environmental requirements document defines the values to serve as a reference point for establishing environmental effects. This document takes into consideration such conditions as temperature, relative humidity, voltage variations, frequency variations, total harmonic distortion, and seismic disturbances. Minimum requirements for storage and transportation are also covered by this specification.

4.8.3 Maintenance Manuals 4.8.3.1 Hardware Maintenance Manual The hardware maintenance manual provides additional information beyond that included in the hardware design documentation that is required for hardware maintenance.

4.8.3.2 Software Maintenance Manual The software maintenance manual provides additional information beyond that included in the software design documentation that is required for software maintenance.

Ma 31 1996 Revision 1 m: 977w.wpf:1b-061296

5-1 5.0 DOCUMENT CROSS-REFERENCE 5.1 DOCUMENTS SPECIFIC TO HARDWARE Document Title Section 2 Hardware Design Requirements 4.1.3 Hardware Design Specifications 4.2.1 Hardware implementation Specification 4.3.1 Electrical Assembly Documents 4.3.1.1 Mechanical Assembly Documents 4.3.1.2 Wiring Diagrams 4.3.1.3 Internal Connection Diagrams 4.3.1.4 Internal Power Distribution Diagrams 4.3.1.5 Hardware Verification Plan 4.4.1 Hardware Verification Test Procedures 4.5.1 Hardware Test Results Report 4.5.3 Hardware Maintenanco Manual 4.8.3.1 5.2 DOCUMENTS SPECIFIC TO SOFTWARE Document Title Section Software Design Requirements 4.1.4 Software Design Specifications 4.2.2 Software implementation Specifications 4.3.2 Source Programs 4.3.2.1 Object Code 4.3.2.2 Software Verification Plan 4.4.2 Software Verification Test Procedures 4.5.2 Software Test Results Report 4.5.4 Software Maintenance Manual 4.8.3.2

• Of this Document m kb w t1b-061296 l

s.$ s.

5.3 SYSTEM LEVEL DOCUMENTS (includes combined hardware / software documents)

Document Title Section System Design Requirements 4.1.1 System Functional Requirements 4.1.1.1 j System Block Diagram 4.1.1.2 System Design Specifications 4.1.2 Composite Block Diagram 4.1.2.1 Reliability Analysis Report 4.3.3 System Verification Plan 4.4.3 System Validation Plan 4.4.4 System Implementation Specification 4.6.1 System Electrical Assemblies 4.6.1.1 System Mechanical Assemblies 4.6.1.2 System Wiring Diagrams 4.6.1.3 System Intemal Connection Diagrams 4.6.1.4 System Intemal Power Distribution Diagrams 4.6.1.5 System Verification Procedures 4.7.1.1 System Validation Procedures 4.7.1.2 j System Verification Test Results 4.7.2.1 System Validation Test Results 4.7.2.2 Extemal Connection Diagrams 4.8.1.1 Signal Interface List 4.8.1.2 Extemal Power Requirements 4.8.1.3 Field Separation Requirements 4.8.2.1 Environmental Requirements 4.8.2.2 Mg1g, Revision 1

l

- 6-1

6.0 REFERENCES

6.1 ANSI /IEEE ANS-7-4.3.2 (1993); " Application Criteria for Programmable Digital Computer Systems in Safety Systems for Programmable Digital Computer Systems in Safety Systems of Nuclear Power Generating Stations" 6.2 IEC 880-1986; " Software for Computers in the Safety Systems for Nuclear Power Generating Stations" 6.3 lEEE 828-1983; "lEEE Standard for Software Configuration Management Plans" 6.4 . IEEE 829-1983; "lEEE Standard for Software Test Documentation" 6.5 IEEE 830-1984; "lEEE Standard for Software Requirements Specifications" 6.6 IEEE 1012-1986; "lEEE Standard for Software Verification and Validation Plans" 6.7 IEEE 1028-1988; "lEEE Standard for Software Reviews and Audits" 6.8 IEEE 1042-1987; "lEEE Guide to Software Configuration Management (ANSI)"

6.9 EPRI TR-102348, " Guideline on Licensing Digital Upgrades" 6.10 EPRI NP-5652 (NClG-07), " Guidelines for the Utilization of Commercial Grade items in Nuclear Safety Related Applications" 6.11 EPRI TR-102260, "NP-5652 Supplemental Guideline" 6.12 WCAP-12885, Revision 0, dated March 28,1991, Westinghouse Nuclear Services Division Commercial Dedication Program 6.13 EPRI TR-106439, " Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications" 6.14 WCAP-12601, "AP600 Simplified Passive Advanced Light Water Reactor Plant Program - Program Operating Procedures", R-" rTo Be Established Later)

Revision 1 M g 19

---