ML20070D816
| ML20070D816 | |
| Person / Time | |
|---|---|
| Site: | 05200003 |
| Issue date: | 06/27/1994 |
| From: | WESTINGHOUSE ELECTRIC COMPANY, DIV OF CBS CORP. |
| To: | |
| Shared Package | |
| ML19304C368 | List: |
| References | |
| WCAP-14081, WCAP-14081-R, WCAP-14081-R00, NUDOCS 9407120351 | |
| Download: ML20070D816 (82) | |
Text
_
m
^
.e...',',
....e.-
.,n....
.,1.+...
4'j,', *
.g r :.
, (
$', [,... ".....
v.-
...... e
- e ;g'.
.,....<....;,... i', I N '.';. '[ #',.;.
} j. '. 7'..,'.. *I ' $ *.,.'*%y'
[.[ ~.'
k:'. ; i.,., ' #.,.,'2[... '. '. '.. '... '. ' ' ', '...
^.r.'..,[',:.. : j...
]
- ij,: 9 ; -
,v..",'.'.
k
'r.
g:
2
.......,'.,......'.'..E.1'.:h;;,M'*
. ' 7 M.[
.'[.";.'.'..
.........g,.,..,..< '.,.. '....
,,... - p.s r
w....
..s.,.
.g,.,
n.
a.
..2.....
s.....-
- c..-.-.;.
. n.
.....,.n
,.r...
. _... _....3 l
.r.:...-r..
,c..;.;
l.{ _.l [ : ;[ lY _ ;;..:
..c.
- 9..
~<~.
8
?.*),.,
w,.
- ! ; ?; f....,,: ',
c,
::
- N,- )ll l. ll*[ ;, ? ). [;$ ~ '. ?
. J :,.'.,.:; ' q;.,.'.**
- 5 '. g.
, y
' '.,*'ja
,,. s :..,s. ;.T, *..'..,: :'..;.-.:.;;;, 2
>,..n
.,s**+
- .. u ;
- v. :...
..... -..':.~,.
5.. < : 3.. Li'
...;.:.. ;...; a. 3; >, :
,..... "4. : :.. :?..:. :,....;...
7:.. ',
.;. ;.y
~%'..
t.
a:. s:
n.-'.
'. ',
- n ;. v r. : :.sv. :;
,'..~...v. - a ":;
.:.... :..g.g
.m e ;, ;L.e'...;;.
.... ~ u. s..
O,n,y...\\ ;. ;p.+
e
. p....::
.s i,.v.
3.;,,.,. :::
y m
- +~ -..:
=
- 3.. e p.
.. u y., 7;.
.,w.
v
- ~ 3
.1
=
.\\
n 1: :,
,c.g. ~. u..y.- :.,.. __, '
T.Q. < :, -
.\\
s
,..'.. ;.;.O.:.:-q,,
{-[ 3. ::. /..,,..:'..L.. a.:..
4
.. - ; - -....; _,.. ;.. _. : - ~ :..! :.,.::.<l.
n_'.
r
. g.+..
.r
............y.;.w:
...e
- ... ;.v :, :)A....r
- ..., y 3.-_.; :......+, ;, ;,. c -~;,..._,.;...,,.,
... f. ? '^
s.
_3. ; <_ = ;;....
. n:
.. s
..; l I,..f,.. L. ; ;.:.~..a f. 6
[ '. A. i..l':l., i a '. i *-" '.
...,..J;
&.{..'..C) O, ; ; i, '.Q.;2 l...
m,. L ' G.l;. _. : " 'j..l,')..; l.. : !.,'e +."..
77 '.
,' I;L. ; ' 3'
,. '.'. i;....I.. :
(
..:.e....,
- ... V. OM-l.
- .V.;7
- . '. Q. % f_.&
'; ),*:';? }:
c
-' O ~' ;.j ': ;. j,'. : -.' J. *
... ' ^*"- *..l..
- l
- l:..~ [ ;::..
- ~
q.n '. %.' ', :...
e
..,e.n...._.
~...+,.. - - ;.
/. :.
..v
.....v. :;..: :m
..s..,.,..;,:'. q
.....;.. )y
_,.. ~....
- ,g,.J [.v.
,,p
....c..c.
.._,.... '.....y'
.:... v:
- a.. ;
',..n..:;.4...
...o.....;...:
v',,:.,,:...,.n ;...- vl : ; /
- s ' /..:. -;;-....,..
..'.c 2 ; ; ^ h,.'-l.
-. f.. v.i'., e '., l g.... _...-. y..'::
M_-
- t...
,.F
..tw
..a.
c 3
g y.
...; s y
j.:,, i Q.. :.... _.:.;j ji j. ; ; *); ; ~
- 9. n.:3. a.
,.;' R. ' 4 ;; c.;L;.J::
.W;
/ ;v
,..~
_y ?.
n
.. p. y ~ m;.; -
- v. h....
- ..~.:.;_.... v:. ; : *. -
..;.. S.
v
-.~
+s..
3
- u
- . 7 '.
- .
r u
..p_,
, t :' 3. < ;;..
.a
- p \\ --
. y:'s. :
.~.yA v.,...
. :a, n s.: ;: ; c",...n...p...
- .. i
... :.; e n %' :... 0 :.w;'.c.,@... 4.B :. q /.: ), - V v....;. ;;;., :.
- ,,*:.. :c.p.. s,:s. ;,.: ; / ;,,. -..a,.
~:..
q.,,.'.s<.~e.
L.
~:,-::. -
.. ;2
...m,,.-
a.
..m::.
..;:,.....-.~./.e..s."....,,U.Y. ' ;,': < '.. -:..,.;;^
.'...._.-. ;.- i
.... v y
- .5 m.t;'.7. :f.....-: ;...
~.
^'?*d
.w. v
..s
.. ' .4'*"+'g
~n.'
a*
.*^**'n~
- z; -.' '.
L-?^.." v.
. ~.., ; L.-
~c V ^: w
,. :.u c
v.
1
.m e.: : s.' 0. v,..a..mw. m....,r.......
' 4. 7 -
.1..
p :...
+ s.e.
w:...... v..-.; ; ~.
.y 1
.7.(..-.
.+. ' k ', _ j,, _.
q). j,..
..,b. '..,,ef ?.p*[..
.a.
M
.'t, t'
..;.'.n'
.g
/..:[,r.'T,-..,[*'.',,..,f'.'.*.7,.
- --:. : n
...]+. f.
.'\\... ' ". i.l-
_l,. *... ' '
+ %
Q',
s'
+
1--.
-e. :
WD.f]4..:.;7.i ' k.b. J.M. +.,
j
< l ; :,f,
, a.:..
- g.
F4 4H,fi % fl AP600 Instrumentation and Control l W:nn,1 <3 4 ; ::
.0 >
? 7 -:
i/f js Software Architecture and Operation
~
4_.
- .c
, x,p..w.. ;f...., q., y : 3,. :; c..
t,,rflp Description i ;.;
x..
- e. -;. v..u.y 4.,.... -
- c
-- s..
~ - :
s,v'. :...>.
j.c..,..:w,
.. e,J..,:.,.,.
y '.'+
- e. -.... a;c ai
- ,-+.....5.,.....,.
v
%i*
,,;(...I, d
t w--
a
.' 14...,
,e.
g
- c....
..f...,,
w
<.5::q.:,:.t :.
~
.. '.. '.. L..:..,.'.a
. + --
gp
.s g.
y.c; ;.. ).. c. _ h.. n h.). '*'..;
' p*.::, %.;.
.Q..m~
u.
s
- )
s;i
,:..e;.o,.,..,'...
... i,.,.m.,,.~
~
7
~-
s.
. z.
.. w..
..,. ~
...a x/q.b....- y:. q :..
- *., ;:g
..)......y.,4..:'.; 9.:l ~. z.. :...y :y. y. ;..;g :
=
p ' ~ :'. ': -
,.m W:,..*.. U.: ::W,,.:.<- ^. '....<
m
, l'
, i:..:%
+3. j.
.p
<,. :.. 7.v 7.a
- ... -,..c.,.~. 17.
=--
< y., c.
..N.-
5 '..~' s.. s.,,. y
..g.
i,1 ;,1
.,..,;,>;*.-...s.;.
h).,., ~. *. -
u_v3.a...._;..,........
-,.,, '.sy '.,. v.. _ ;.y :.....j-,
..y
.3-.
m
.r.3. T. o..0;...'_g>....tv-_..jO..,...
- ,...
- .,a.......;,
-y
. ;: : o
.: ',r... -..',,,Y.,.'.:(
.e.
..,.~.+::..
-..g.
... c 3...
-o
..v
. 'y,
.- 3 N-
.... <;. +'.,
,.,, \\ y'
- s p,
, :v; ;.,. : ---;
.; 5.u,. :il:.M.O.3,k ~ f: ;;f,,;' Q
,.'y,..'.-.
. (.,. :> w,. 9... 1..,.,.:.R.y >. ; eu...) y '. ': 1ll( t
- v ?l -
m
.t. l y.. : ; y. /, ; :,;.,... v..e,.,..... c f., t,s.'..,. (-
.*+-...,....:;.t..>,.,
- ....-..:,.o...:
.. s..; ;..3,,.,,)t.,. 3. 'm_;..<_
-;.,:..u:
,a L..
c..:; ;.,..
g,.;. :, v
.:.r j
..., ~
=-
....y c
.; ~,,... ;n., ;,. s,.. t s
y3
~.
4:
-.y 7,.,.
j - -....;.,'....~.;-
- n. s..'.-1.. ' ' - l. ;,;f.}
n
..:.g 4
- .s ;,
- ..a.9_...,...s.....,....,'..,~,.....:.
+,.. -.
.o.
~
t
... '. ?.., ^ l., Q :. -l *
- lT;'.,.e
- ..,9, '...+g.
L;.0 :.
.'*o.,.*'.
};,
- 4,, ?. ', 4 3..-- { [ :
- .,<.~.',..y L-J.
.,'.;....... ~.;......
c
..t.
. -.- i_.
~..
.6....',/
.. -.... -...3,
,.<e
):
.e y......,,,
+
.,7,._.~..g; ;,,.e,
.,c
. y
....y...y;a v -
+
2.,
,,...,. u P:,., y ".. - ;. s L,',...7....,jr.,..,,. ;. ; 2.
- ,,i [,.;.;; ;. ;;;..[.
' w,- l 3 i
-p,.~..:~...
_m.';;
- .,. - :- F y;-..',;j..;.5 - * '. < * * - '
- +- - - -;.... p;; *;.:k;. :
..,i.'.,-_'.';,:..:...'..-[:.
,:1: -
..n-
. *, ~ - -'
- n.*._;. ;, :[
c.
~
_ (
r
,;,s.,
.$.[.6..' ( * :. -, -
v: -..-.., _ '..,'...t
,,J.,...
- .,^ ~- ;. ;..... +
+
,3 5;
, w..
..o
.._.,..,...., ;: ',;...*,L
+.',
^
- .;p, *:[ ::. ' _ _f..,
p..
.. - ~ :l-J. -
"'[.','.r ',.i _..:' ;,.:..,._.,:' '
- ..., _ _...,'. T..,_., ;... -.,-..
?,s s.-
, _. : ::: *., : . * : * ?
_,.,.-, '.,.,-,-_ ;....,...}
-,2
(
p 2,_
c.,.,_, '.. -.~..-
,.g
.: ;?
., _ y,_
y _
,. _ ' ', ;; y.,,, " *. - -
.v, c. ;. -.... $ -*
+
\\.
t t :.'. -. y
. *..,,... -,f,.-... 'f'*'
,-4
?
- '+'.'o
,.,?=.
+,
e,e -.
,'.f
' t"
...,.+
. ',,, -, + -'
,g..
.; ** ' ' ~.,..
r_,
<*e..
g *, * *,
._.'.;,.3,*,,[,
f.
t;'. ' * -
- .g'.
g, 1[ ^.. - {+:,.
,.,,;* i 1*
g,,,*
l
,g*,
L
,p'
(,
+, ; ; *
,t; ;.
...:.......;; [.
e,
- (
.4
.",[.'...,.,.','..
. 9s N g.,
.x',.,*..
._ - <.v' a : 5**.,
J
... % 9.
- ...a... +. '
- ',. *,,, + * '
.[
f,.,
,.,8 *, '.,, ' - - <...-; ', '. ', '
q
..r.
5..
.[
.J
. 'E.-'
,*+
O,,.t., - ','
l*
,4.'.q'%d.
f.
- i N* * *-,,,
.I'.*
[
4
'.;+a' -,..... ',., '. ,..
',,,e,...,..'
'f
+
- .I,,'.
+ *, ' ' '. _
'.. '+
.,..;,,'.,,'.1*
l,.*.,,
. j'... '. '...
e'-
E
', ' ',,',l+
- j.,
8, ' k,.
+
.NE*
E*
,-.,i[
, _ [
4.
..,, +
'+
. i f
- e
+
4. r,..
.. ' ' '.. '.[, [.1 ' ';.,,.
4'
['*',
- k - '
- ' [,,(' h, } [
,'4.,',
,.,.,p.-
,,, (
.,.g[
. ',., [ (
- F[
[t! '?
[.'
I *. i+
- ,.. +,
gL,.
.',,s,.
,.r ec...*,*..... ' g.,,
,., -..*,.... +.-,.. *,.;.-..,
- f.+ 4.,.,.',','s
. +
t
,n..
,.,o ry,,.'.,..
,,.,. ',.+*
^
A e
4*
'E'.
.f*
3, *7,, *...
4 i
E;.
h
.+'a.,- s;**'-
.C
,,, '., -.,'?-..' ** [,'.,, '. * '
.[,;
5.
+ - q',.,
.,,.-'.7.,.i.,6,m,, g, ' ~,,, c ',j, _
..=.4
- , s.".'+',
- ,{
s.
e 3,'e ;.. **.,. '
- l..,
e.,
,.a-
..,,.,g
/.y',,.,
+#,
^g--
e
-, - y+',4
'*y,'c'-
q *
- ..e
- t-
.:-';.-d,-,,,,, -
'3.
- y(..
,j g
p,
,*c.;.-'
- g..},p..*
l.
,.:.:,.,.,..=,.,....._n,
+. ; -. <., "...,,,.
J.
.1:,-.*y,...,.,i.,.......,.
4 y
er:;',
.v,,,..<z>,..
.. u.
- .
- v.._
.* ; +
,j
.v
.._.3
.g
,,,,;;..,3.'..,
. ' r e
A p
c,f,;,..,'..+,,..',;,,)>.:.
- Lv. r.
s,.v39.'.,
p.'.-,,.,,
- ,-.~:. <,- _, c
-f c..-7 4
r.
+.
,, :+
r,
?.
e,
.y';.'*.
- ,t
-s
.*m m. L...; -
r!
y,<
v
..s.. ' '..,
.?.
g y [...; : ' 'N *.:Q.....'.,,J.
u
'. **r
.s a..
.-T, r. lu
.L-m--
.v.
v
,.j.s.,.
.. ?
~..->,...,..,.,,.;L. _
.).,-..,;.....j.9.,.. f.; ' 'v
- 7. i -.g'..,~.
. s s.
... f :.,, *
[',
..r
.,.L.:.*..,.i.._..
J.;e. :*. :L : ;,,
c a-.
7-.-
.,,r.
?+
6,. +.. n. :..,.
t e
s
,s
.., '.. -.Jp.' n' ;-
-,,.,,;a
.4.....a,.,
.,.-,.,..f....;>,3~.,.>...
,a,*
s,..
.,-:..s,..y
. 7.:.c a
_.,,.,:)
e ; \\.
- u . ;:.
j' ;..
[
',l,._,,
._ ' ^
',\\,'..'
+.
-u.
1 1;: & r..,'A y, y.:..,..',..i,;ts.n' 8
a_
.v Jr,,*... ';.,...--
e' e,.:
.t
,., n. (. *,,.... -
- y;....,,. '.,., :,, _j,.-,....*,Ne:;.
.. ;j,.,,,
,..y.* y _
, :a....;., *.,.
i.
.v,
. y w
.. ;., ; v,
,.s-,.,.
L._
..,., /.
,4 g
.t,.., 4 5
- .,e.
,.y,
+. (;
,,...,.4.u..,,.,
.4
- 5.:.......y.
- ; i;:.' ;.,,.o/,,.,i..,
..-; :s ;: ? *.~,. y?...*%.,.n.-*::,L, g..-.
.,v. _...,;,'.:.r.
.,.i. p..,
r r
- + j r., f,,...,. '
n..s,s.,.-,..
s r.+.,, - :n '
- +*..... 1,p "p.-.... ",.,,... ~.,,, -
-35
,...;., - ~..Yr. -.. g
~
'.,a.../.
4.,,s.
+e
..%g.. u s.. -~...s,.,s'":t.,-
y
=
r.
t
.s,-.-a:.,'.w
.,.s.
-,.~...:..':,'m...~t'.,f....
y...t m
v 1
a
, ', '. j*) ' D..;.
- i, al.s * *-' ;.,
,r,
. v..g 2.::.,. -.. -';:,.
,c
...t'...
e
.c.....,.,.,%:..
..1... y v. ;- -
.3,..
y 4
lt ',
.L.,
- ,1 -
,.. :.v.
r.
, ~ '
....:l - [ r, &. *.b. :.;, e'. :; '.fE),
'.u. )' t.;; *.;;~ ':::
,,'}:L; \\;
." W '. '. ' T< :', 4 :::),a....
.t-s,
, m. 4.~..
,.~?..j.m..,w.
,.'c.
.,?>...*y..'".'s '. ?':,:, L.*...,;..,i..-
-e-i iy*
l E-
.. :. - ** ' L;.. :..:.y1
..1 4
.F.,..
c
~.
- ;. ;a t4.p,.,.,,.......;..
- . :n A Plte..,t'.i..+'-. f,. n.,'. ',.. i:,.? ? ?.w n... '. ~,
<c
>V.e' o'/:, ':.,
- t-
..3
- '. *, c... J.
- ., L
<L.:;.;>. ",.
u-
. '., '- '. ;a
~.
w
.e ' i. 7.,.,r', H.f...
.'t n,<.
t s-
-:...*;.;;...i..a..,,.,... T.: f, ., :::, :._.
2.
,. [ ','y -,; 9,, ~L q ;
- o.....,y ; r < - -
..-.. ~. ', e':.
. -..r. t ;. r. ~4 ;g r..r
.co
.t......f.;hgn:
.s.
e
. y,
m_
!.m.: q
~4,., ;. ~ ; -., s n..:
~
3
- w..--
,-.,c,
,.s_
=
,r
_..e a-.
t.
.,:.c
- 7 j.....
,e,. :.: :..s'*
('
- i.. '1, r':' '.;, ;;
=
y p.
- . % (.T t
- +.,,
,e
,, ~..
v t..,
.:L,.3. + + ;,,,,.,, :
y
.b i::. y. ;.
.?;.*
- ..;3...: *..; ;- ;.)
,..,.,.-....'.f,.',.'q',.wt.{:.*d. r *'f. : '.s.e*Q* '*,.*;.;.~,.;.L
. f.
' lp }Ag...:
.n..
- -.., l,, ;,. 'k L, a
(L,d....'.'
,4*
- r,'.
- i
,%,[;**s ;).;
- ,, } ?.'. S
,....T_V
'. Y. _',. ' '. s. ' *; :. *a,.. '. '_.l:. M. :
~
'.L }..l'
- f :..f:. l } Q
- j.;,.
- .. L ' ['~. ~, \\ ' ' ;'*,'..,A,
~
.,..s
?;
}l.
y '. _,; +., * '..
- .?.,.:..
o v.
l> -
,..,,.\\:..,).
4 4
_..,.,,...,...... d; : '.-
c..,. ;;:-)
p _ ;.
a,,
+ -
),,'+>
,a'v,a......>,.. ' - '..~0,
- _.*._'.r.-..'
p a;
y
.,..s v.i ::.. -....
,..c-3
'..,;,.;. c.. '.;'.,.;-.-*. -.., - _., -,..,.
>,,- ~..
+
.a r
a
.'..f'..,._....'-l.,
g:
s,~.
.;r f.. &.,..l1*t.,-
-;3,
9',.';,' ), y l
_o., w,. \\
V
. 3., * ;. '.,. y ;.....
..,...'..,.';*9,.,,._,.x.
.f
'?
,: 4. 5.,
.,1. :.. ;; ', ',
,L...... x, -...,.. -
- ; c.
+
c, ;:,;.,
g
..s...
r
,t e
i
-. _ _....sw.
-t.
...< ;.,-.i m
4
- - -.. +.
.o,.8-a.
.,,.,,6..
I s.
i
- fY. -
.n ;,..
..,.5 t;.,,...,,-..,:c.,.g.,,;.......,
s.s n,,.
3 ',. p.., ;.....-;.W.
. ~. ?. ;.A..,<.,
v....,,
+ v.
p? *...... C....,r'n. a..... r.. :
.w',.,...,*'
p~ s.,
r '.,
~..,...s. ~;* A. T *. -
,., c. ts,,,.,*
,.n.. {
s
'..-n*~.
c L.,, s.
.'.;t.s.,.
..*u.
-l l_'
n....<,...'_'l[.
- V a
r,
- ,,n,',-l*
- +
.,.ss..-.
..ys
. 4 ;z r* '.
- n.....'.e
-r
,.;r:
q.:.. " i, ;..'.,,. :.
w'....,.,>.'..e
+.. '
L.*,'
v,'..
.,.e
,. i..:
,3, c.;,:
.?. '*. :
s.
,..,',,.,c..,.,.,..-.
...... z. _,-
.,.e.,
N.
v, ; y' r n.
^;
~
r
}:7 '.x
- l. 7
.a
,.m p. y..:.
.;.'...?.,,';
n,
.. n.. : :... ~.,.. %. ~ *. :.. x'-.:
.y,..,.;
n,.
m
. ~,,.. - -
M
.).;.*.. _- r,.;..
.w
,.r, ;.
<.s
.. c,,.,...
s.
~
- 7. 4.,.,3. ;. : w.
.. ;;;;..v. :..,. _,.
a :.; :.
..~...3
- s..
.....e...
....o.,..'(.
+.-.
.,., j :
- b,
,v.
. ',. '.,.*c*
,.. I}..{..
.'t -.
- n.':.. '.,...., ' '. '.. "..
Q
. +;'..
.a',
2?., j,p... -.'.e.:.'
- c
_'s-
'.., '. +,. ;, ?. . \\
I
,_.,...,l
-,[ ;%...
..... +-.. ;
+....
7..
- : ?..
...,.n
. e,
.4
. ?
.....~. ; ; x. >. ~.
. ~.
+.
-=_
1..>.
..,, ;.. m..
..y_,...
., : +.w c.
.. 4.,,;s;n ns ; ;. 3.. x x.;~>.;: y.:.;.,..
.;, s... ; y.. n.,.2 :.,,...,, 9
.,.c.... e. "..
,s.
s
, : ~j.. ;.
3,
- m...
t.,....e
, ~. ~. -ue x..,.. c..,-
1:.
J t
p.j
,t s.,..,....,.n _.,,.., m.... : :.,. y 1.t m< ;..
- 3... w
- c.
- s.
rz.,,
~.
.....;...+.
... n.,
.r:~.....
.c,.....
g m
y%.,.
- _,. :;,,. - e e
....,.._.,,3-.
..,, n
. n.,,; w 3 ; y'n.,
.,r
[:.
. c : ;:, ~. c.... ; :.. -
- a., ;.;. ~.. m_,1
.e :
I m
~-
+ '.., - ;
c..., c,. n.. y ;.c... '.,,.. ; n.
..,....e
.,...s,,..,,..,,.,.s..;...
v: >.
1
.,...,.. w :
i
.. n ;:.q.
.a:
.; c.g.y :
.u ~...,.., :..c,..,,.,,....,,,. +..,
c.
,N....'. a.
- 3..
w
- c..;..
. c...,,,......,,,..
7
..c
.S#..'
M M S b 'i:
i. t F l..,... v.% m N'# n
%.:a; c407120351 940701 S 0:
w 1. s:::
D. V...JM.cy.M.. yU@ M's ff?"1Wn C. A.R. $'30.N+. i f '.dO
.C.
n..
PDR ADOCK 05200003 L
Wn%NQ%d;:, %is f Y: N.a;.
'l. ~.1.~.:
"W
- 4:1 PDR W
o ".x 7 ? 0"D::
W 2
A A.
- G.: n.6.
..a. x x.5:l.,m. --A..::.9 y).:,:] TWh: M Wlz.V::l.avu:M!i.&. :.
.x
.~ v-
.. o-
- ~. :.
w n:e -
k M%@.
- 0.,r.
iW.X
.:t;.
x
=__
r WCAP-14081 2
b AP600 Instrumentation and Control Software Architecture and Operation Description I
l l
L J
i V
c'
)
4 c
1 t
Westinghouse Energy Systems ~
W
==
9 e
9407120351 940701 PDR ADOCK 05200003 A
WESTINGHOUSE PROPRIETARY CLASS 3 WCAP-14081 Westinghouse Class 2 Version Exists as WCAP-14080 AP600 Instrumentation and Control 1
Software Architecture and Operation Description i
(C) WESTINGHOUSE ELECTRIC CORPORATION 1994 A license is reserved to the U.S. Government under contract DE-AC03-90SF18495 WESTINGHOUSE PROPRIETARY CLASS 3 l
l i
l i
Westinghouse Electric Corporation Energy System Business Unit j
Advanced Technology Business Area P. O. Box 355 a
Pittsburgh Pennsylvania 15230 e 1994 Westinghouse Electric Corporation All Rights Reserved
WESTINGHOUSE NONPROPRIETARY CLASS 3
)
AP600 Instrumentation and Control Software Architecture and Operation Description Foreword The purpose of this document is to describe the architecture and operation of the software used to implement portions of the AP600 Instrumentation and Control Architecture. This is an informational document, intended to illustrate the software design principles and approach used in the Protection and Safety Monitoring System and portions of the Plant Control System. While the information that this document contains is technically correct, this document is not a design document, and is not to be used for detailed instrumentation and control system design.
Special thanks are extended to Ken Lunz and Bi!! Ghrist of M(PCD for their assistance in preparing this document.
l
)
l i
Revision: 0 June 27,1994 i
i
)
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 1
Table of Contents 1.0 Introduction 1
1.1 Scope of Document 1
1.2 Software Design Goals 1
1.3 Historical Background and Experience 3
2.0 Hardware Description 7
1 3.0 Software Design Philosophy 8
3.1 Software Development Process 8
3.2 Software Design Principles 9
3.3 Software Documentation 17 4.0 Software Description 18 4.1 Software Architecture Overview 18 4.2 Subsystem Functional Processor Loop Execution Sequence 23 4.3 Organization of the Software Functions in a Typical Subsystem 25 4.4 Subsystem Level Data and Control Flow During the Execution Sequence 33 5.0 Software Testing and Verification 55
~
5.1 Software Testing Strategy and Methodology 55 5.2 Software Design and Verification Documentation 56 6.0 References 58 6.1 Westinghouse Documents 58 6.2 Standards 58 6.3 Technical Papers 60
.i l
Revision: 0 June 27,1994 ii
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description List of Figures 1.1 Evolution of Westinghouse Nuclear Plant Digital Instrumentation and Control Systems 6
4.1 Software Architecture Overview 35 4.2 Typical Functional Processor Flow Diagram 36 4.3a Subsystem Level Data Flow Diagram 37 4.3b Subsystem Level Control Flow Diagram 38 4.4a Subsystem Level Data Flow Diagram - [
]"
39 4.4b Subsystem Level Control Flow Diagram - [
]"
40 4.5a Subsystem Level Data Flow Diagram - [
]"
41 4.5b Subsystem Level Control Flow Diagram - [
]"
42 4.6a Subsystem Level Data Flow Diagram - [
]"
43 4.6b Subsystem Level Control Flow Disgram - [
]"
44 4.7a Subsystem Level Data Flow Diagram - [
]"
45 4.7b Subsystem Level Control Flow Diagram - [
]"
46 4.8a Subsystem Level Data Flow Diagram - [
]"
47 4.8b Subsystem Level Control Flow Diagram - [
]"
48 4.9a Subsystem Level Data Flow Diagram - [
]"
49 4.9b Subsystem Level Control Flow Diagram - [
]"
51 4.10a Subsystem Level Data Flow Diagram - [
]"
51 4.10b Subsystem Level Control Flow Diagram - [
]"
52 4.lla Subsystem Level Data Flow Diagram - [
]"
53 4.llb Subsystem Level Control Flow Diagram - [
]"
54 i
1 Revision: 0 June 27,1994 m
J 1
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 1.0 Introduction 1.1 Scope of Document This document describes the software that is used to implement the functions of the Protection and Safety Monitoring System of the AP600 necessary to:
Determine if plant safety limits have been exceeded
~
Automatically trip the reactor Actuate engineered safeguards equipment t
Provide safety grade plant monitoring, prior to, during, and after an accident or plant transient.
This document covers the software used for the instrumentation and control cabinets that provide these functions. The hardware that is included in these instrumentation and control cabinets is described in the related WCAP-13382, "AP600 Instrumentation and Control Hardware Description,"
(Ref. 6.1-1). In this document, the software architecture and operation is described in terms of design goals, design philosophy, and implementation.
The technical details discussed in this document are typical details that represent the present state of instrumentation and control design, and are included in this document for information purposes only.
~
Westinghouse reserves the right to incrementally change design details as long as such changes do not reduce the ability of the combined instrumentation and control software modules to meet overall i
system functional requirements.
1.2 Software Design Goals There were a number of important, primary goals that were addressed and used when initially formulating the basic approach to the protection system software design. These goals were based i
upon the recommendations of IEC 880, modern software engineering principles, contract specifications, and upon Westinghouse's extensive experience in the development of software for real-time safety and control systems. Among these goals were the following:
To design the software architecture and operation to be compatible with verification and to implement it in such a manner that it can be thoroughly tested without great difficulty.
To keep a sharp distinction between applications function software and common systems support software.
The software is segregated into applications function software and common systems i
support software. The functional requirements of the applications software are Revision: 0 June 27,1994 1
i
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description derived directly from the top level functional requirements of the protection system and are plant-specific functions. The functional requirements of the common systems support software are created to support the computer system architectural design.
These must also be compatible with the top level protection functional requirements.
Westinghouse believes that the reliability of software is improved when the functions derived from different sources are implemented in different modules.
To make the applications functions as simple as possible.
The ideal is to have a one-to-one correspondence between elements of the functional requirements and simple expressions or calls to common functions procedures.
(Exceptions are in the areas of software initialization, self-testing, and fail-safe design)
Westinghouse believes that this approach helps to increase the probability that the protection function requirements will be correctly translated. This approach will make it possible for the functional requirement specifier to verify the implementation and also will readily accommodate changes to functional requirements.
To conceal the details of computer system services from the applications functions in order to simplify the task of the applications software designers implementing the protection functions.
"Information hiding" simplifies the application software engineer's task. Errors are less probable if every designer on the project is not required to know the details of computer systems services software.
To develop a set of common functions modules to support a wide range of applications functions which could be required to meet system functional requirements.
These common functions include both computer systems services (analog input processing, communications, etc.) and commonly used applications support algorithms (filters, time delays, comparators, etc.).
To decompose the common functions into a number of major functions with independent internal designs and where the details of data structure design are isolated where practical within individual modules.
This allows each function to be developed separately, so that design decisions and design changes in each case have minimal impact upon the design of the other functions. A partial exception to this independent module design goal is the use of a standardized common design approach to software self-testing (e.g., range checking of configuration and calibration data) and error reporting. However, this is not an actual coupling of the internal designs of the modules.
To concentrate as much of the software complexity as possible in the common functions.
Revision: 0 June 27,1994 2
1 h
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description To compartmentalize the complexity into independent modules.
To develop the complex modules early in the project so that the maximum amount of time and resources could be devoted to carefully designing and testing the most complicated parts of the software.
To implement the common functions as re-usable modules that are not required to be recreated and reverified for each instance of their use.
This applies to re-use for different systems, different plants, and within a giveri.
system. Westinghouse believes that the likelihood of software errors is increased by having to design, implement, and test a series of essentially similar but specifically different analog input processors, shared memory handlers, etc., for each subsystem in the protection system.
In conclusion, the one ultimate goal of the system design, implementation, and verificat tn process is i
to produce a system that reliably performs the functions defined in the system functimi requirements. These individual goals are only a means to this ultimate goal. Many different software development and testing principles and methods, which are based on both theoretical and practical understanding of the methods that produce reliable systems, were employed in concert to achieve this end. Each of these different principles and methods was important, but no one of them alone guaranteed that the end goal would be achieved. Instead they were applied together in a balanced fashion to achieve the ultimate goal of reliable software that meets the system functional requirements.
1.3 Historical Background and Experience Westinghouse has developed considerable expertise over the past 20 years in designing software-based safety systems. This experience has included various development programs, upgrade contracts, test programs and significant field experiences. It has enabled Westinghouse to continually improve the design process and software integrity by building on the lessons learned and experiences of each program. Figure 1.1 identifies the major milestones during this 20 year evolution of software design.
The initial Westinghou:.e program to develop a software-based safety system based on an integrated system concept began in 1975. This first generation system was primarily based on 8-bit microprocessors but also included some analog circuitry. The system functions were limited to the reactor trip system, the system level safeguards actuation and the major control systems. A full scale prototype was manufactured along with the development of the software to allow for qualification and validation testing. This first generation system was carried into the licensing process and resulted in a preliminary design approval as part of the RESAR414 program. Although it was never implemented in a U.S. plant, this system design did become the basis for the first French digital instrumentation and control system as the result of a joint development effort and is in operation in the Paluel units.
Revision: 0 June 27,1994 3
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description The second generation safety system development began in the mid-1980's and was based on the 16-bit microprocessor. The early stages of development were a cooperative effort involving Westinghouse, Nuclear Electric, Mitsubishi Electric and an Italian industry group. The program eventually evolved into the Sizewell B program as the first plant application. The technology which was developed resulted in the Westinghouse product line known as " Eagle" which was entirely based on digital technology. The first Eagle prototype system was completed in 1987, for use as a hardware and software development test bed. This was followed by a Sizewell B specific prototype in 1989 for use in the various Nuclear Electric test programs. The final Sizewell B Primary Protection System (PPS) was delivered to the site in early 1992 and has since undergone a year long on-site commissioning test program to demonstrate both its reliability and availability.
The Sizewell PPS design has undergone an unprecedented amount of test programs and independent design analysis to ensure its safety and the integrity of the software. The test and analysis programs included the following:
1.
Design Assessment Study Nuclear Electric PWR Projects Group 2.
Engineering Confirmation Study National Nuclear Corp.
3.
Independent Design Assessment Nuclear Electric Technology Division 4.
MALPAS Confirmatory Analysis T.A.Consultancy Services 5.
Dynamic Testing Program Rolls Royce & Assoc.
6.
Safety Monitoring Program Nuclear Electric Health & Safety Div.
All of these programs were in addition to the extensive Verification and Validation programs which were conducted by Westinghouse and are similar to the program described in WCAP-13383, "AP600 Instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report" (Ref. 6.1-2). Throughout all of the independent analysis and test programs, there were no deficiencies found in the system design which would have resulted in a condition adverse to safety.
These programs have served to confirm the integrity of the PPS design and the quality of the Westinghouse design, verification, and validation process.
In addition to the Sizewell B program, the Eagle product platform was also utilized for upgrade applications. A configuration for upgrading analog process protection systems was developed to match the functionality and physical configuration in existing systems. This upgrade, known as j
Eagle-21, was first installed at the Sequoyah plant in 1989. Eight other Eagle-21 systems have smce been delivered to other plants, providing valuable field experience on the design.
Eagle technology has also been applied for applications other than protection systems. One of the largest Eagle applications is the Sizewell Integrated System for Centralized Operation (ISCO). ISCO is a replacement for a set of I&C originally planned to be supplied by another vendor. Westinghouse developed a special architecture based on the existing building-block modules and delivered the system in 1992. The Eagle " building-blocks" have also formed the foundation for the Westinghouse Rod Control System, Flux Mapping System and various types of Post Accident Monitoring Systems.
~
Another Westinghouse product line is the Distributed Processing Family (WDPF). This is a digital, Revision: 0 June 27,1994 4
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description microprocessor-based instrumentation and control product line for general purpose process control. It is similar to Eagle-style equipment in that it has modular, configurable, reusable components at both the hardware and software level. EDPF has been used extensively within the non-nuclear process control industry. For nuclear applications, WDPF is being used for nonsafety-related control, data acquisition, data handling, and operator display, such as turbine-generator control applications, other balance-of-plant control applications, plant alarm systems, and distributed computer systems.
Revision: 0 June 27,1994 5
WESTINGHOUSE NONPROPRIETARY CLASS 3 Integrated System Concept 1975
\\
/
1976
\\
/
1977
\\
French Joint Development --4 1978 bintegrated Protection System Prototype (Modei 414)
/
1979
\\
/
1980
\\
First WDr>F cn Utility 1981 k--USNRC Approval (RESAR 414)
I 1982
\\
Japanese APWR --$
1983
\\
/
1984 bSizeweti PPS contract Italian Joint Development --f 1985
\\
/
1986
\\
2nd oeneration Prototypes --d j987
{
1988 k--PPS Specific Prototype ALWR URD Chapter 10 (MMIS) i NOK ANIS Design ~
j989 f Sequoyah Eagle 21 Advanced Digital Feedwater Control 1990 PPS Equipment Manufacture
/
1991 H iSco contract AP600 SSAR Chapter 7 4 1992 h eeS Site commiesioning Tests j
AP600 FOAKEM 1993 h
Temerin contract FIGURE 1.1 - Evolution of Westinghouse Nuclear Plant Revision 0 June 27,1994 6
i 1
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 1
2.0 Hardware Description j
The instrumentation and control hardware implementation for the Protection and Safety Monitoring System is based on microprocessor subsystems mounted in cabinets. These subsystems and the circuit boards they contain are described in WCAP-13382, "AP600 Instrumentation and Control Hardware Description," (Ref. 6.1-1). The software architecture of the AP600 protection system is based on the use of multiprocessing (execution of programs on two or more related processors, in this case the host and slave processors of a subsystem),with single program, non-interrupt driven, execution on each processor. The host and slave processors within a microprocessor subsystem, the microprocessor subsystems within a cabinet set, the cabinet sets within an instrumentation and control division, and the instrumentation and control divisions within a plant, operate in an independent, asynchronous manner. Asynchronous communications methods are used to decouple the operation of the individual processors in the multiprocessing environment. Each subsystem is assigned a certain specific set of tasks to perform. The sequence of operations each subsystem performs can be described as:
Acquire data from other subsystems or I/O cards Perform the specified algorithnis Output the results of the algorithms to other subsystems or 1/O cards These subsystems communicate with each other by means of one way datalinks which carry information from one subsystem to one or more subsystems, and data highways which carry information between a number of subsystems, each subsystem broadcasting its information to the other connected subsystems in a deterministic manner. These communications tasks are performed for a subsystem by intelligent processor cards located within that subsystem.
Intelligent processor cards are also used to input analog data to the subsystem. Other data I/O is performed for a subsystem by special purpose input / output boards.
Communications between the multiple processors within a subsystem uses a master / slave technique to write messages into shared memory locations over a computer bus that is implemented by the subsystem backplane.
Each microprocessor subsystem has a custom designed microprocessor board, called the Multibus Diagnostic Monitor (MDM) board, that provides multiple hardware and software support functions for real time instrumentation and control use. This board and the functions it performs are described in section 3.2.4 of WCAP-13382, "AP600 Instrumentation and Control Hardware Description," (Ref.
6.1-1). Two of the board's functions are to provide subsystem identification to the subsystem's software to prevent installing software in the wrong subsystem, and to monitor subsystem performance and halt the subsystem on a faihire.
Revision: 0 June 27,1994 7
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 3.0 Software Design Philosopby The objective of this section is to describ the underlying philosophy that governs the design of the protection system software and to state the high level goals of the protection system software design process.
3.1 Software Development Process Development of the software for embedded microprocessors in protection and control systems is done using a top-down approach as outlined in WCAP-13333, "AP600 Instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report," (Ref. 6.1-2). Two basic categories of software are developed by Westinghouse: Application Functions and Common Functions. Application Functions are those software modules that provide the specific application functions required by the control or protection system. Generally, each application function is used only once within a system or within each redundant part of a system.
Common functions are those software modules that provide common services needed by more than one of the functions in a system. The common functions programs are developed for use by a wide variety of systems.
Some examples of Common Functions are:
I j...
I j..e I
j.
[
)..c The use of common functions supports the goal of producing error-free software. (See section 3.2.1)
It reduces the total number of modules that must be developed to perform the safety or control functions by eliminating the creation of unique modules performing identical functions.
Jt simplifies the applications specific software, allowing the application programmer to concentrate on the specific protection or control functions being implemented rather than the details of the computer system environment. This also aids in the Revision: 0 June 27,1994 8
WESTINGHOUSE NONPROPRIETARY CLASS 3
- AP600 Instrumentation and Control Software Architecture and Operation Description understanding of the software by persons other than the designer.
It validates the software operation through extensive and varied applications.
It supports the creation of a software library and simplifies the maintenance of the software.
It supports the application of modern software engineering principles, such as data hiding and independence of module design.
It supports a software design approach that is oriented toward an achievable design solution.
3.2 Software Design Principles 3.2.1 General Principles The goal of software development is to pred cc code that is as error-free as possible from the very beginning. To support this goal software must be easily maintained, easily verified, and should avoid program methods that experience has shown to be error-prone. Project software is usually designed and coded by several people working together. Even where this is not the case, it must be maintained at some later time by different people. It is important that the software be structured and written in a manner such that its interfaces are easy to understand and that the software is easy to modify without error when changes are necessary. Software for safety systems, and other high-reliability systems, must be formally verified. In order to meet this goal, the software must be designed for verification.
The design and implementation of this software must be compatible with verification. Even where formal verification is not required, the software must be designed so that it can be thoroughly tested without great difficulty.
IEC 880 recommends the following general principles for the design and coding of software in nuclear safety systems. Westinghouse intends that these principles shall also be applied to software in other embedded computer systems, such as NSSS control systems.
The program structure should be based on a decomposition into modules.
l The program structure should be simple and easy to understand, both in its overall i
design and in its details. Tricks, recursive structures, and unnecessary code compaction should be avoided.
The fm' al source program should be readable from start to end.
)
Good documentation should be provided.
The software design shall include self-supervision of control flow and data.
Revision: 0 June 27,1994 9
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description The Westinghouse interpretation of the last requirement, for software self-supervision, is that the range of values with which the software is operating must be limited, by software checks, to the range over which the software is specified to operate. Verification confirms that the software will operate correctly in such a case. Programmed testing of the hardware is done at restart time and during on-line operation to confirm to the extent practical that the hardware is capable of correctly carrying out the functions of the software as it was coded.
[
l a,c The following sections describe various characteristics that are required for protection and control software.
3.2.2 Languages 3.2.2.1 High Level Languages l
High level languages allow programs to be coded as statements of functional algorithms, not directly representative of the computer's instruction set, using symbolic names for data structures and memory locations (variables). An acceptable high level language provides the ability to write structured, modular programs, preferably in a block structured manner. [
l
]" A single high level language is used throughout the entire system, to the extent feasible. The preferred high level languages for use in protection and control systems are the Intel PL/M class of languages (e.g. PL/M-86, PL/M-51, and PL/M-96). PL/M was chosen for the application, based on a comparison with other languages, because it met these requirements, it is the native language for the microprocessor family selected for the application, and it is widely used.
3.2.2.2 Low Level (Assembly) Languages Low level, or assembly, languages provide symbolic naming conventions, but require that programs be stated as a representation of the machine-level computer operations to be performed. Assembly languages are not used for protection and control systems programs except in those cases where they Revision: 0 June 27,1994 10
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Dercription are required in order to meet timing or hardware interface constraints. Such use is justified in each instance. [
)...
3.2.3 Software Structure 3.2.3.1 Top-Level 1)esign A standard software structure is used in the processors that provide protective functions. This includes the main functional processor of a particular subsystem and also the support processors, such as communication controllers and analog input processors, that provide services to the functional processor. [
l l
]* '
The standard software structure is also used in subsystems that provide direct control functions.
[
]' ' This software structure is also an important factor in creating verifiable software.
3.2.3.2 Diagnostics I
Comprehensive diagnostic routines are performed during initialization. On-line diagnostic routines are performed at the end of each execution loop. [
)..e 3.2.3.3 Modularity Programs are developed as a set of program modules and linked together into an code module with a fixed address, to be installed into the microprocessor memory. In this context, a program module is Revision: 0 June 27,1994 11
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Sr,ftware Architecture and Operatica Description considered to be the program source statements processed by a single compilation step, and the object module produced by that compilation. [
j..e
[
j..c Data hiding is also an important aspect of good design practice. [
j..c 3.2.3.4 Scope of Variables (Dynamic Data)
The use of public variables (those known to more than one module) is avoided wherever possible.
The justification for exceptions to this constraint is documented. [
4 9
3.2.3.5 Scope of Constants (Static Data) i
[
j..e 3.2.4 Exception Codes An exception code is a value generated, usually by a common function routine, to report the success or failure of a requested operation. [
d Revision: 0 June 27,1994 12
.l 1
WESTINGHOUSE NONPROPRIETARY CLASS 3 1
AP600 Instrumentation and Control Software Architecture and Operation Description ju I
ju The assignment of exception code values is controlled to make sure that all exception codes within a system are unique. Since most exception codes are associated with common functions routines, the assignment of code values is kept unique among all subsystems using any of the common functions modules.
3.2.5 Memory Configuration
~
3.2.5.1 Programmable Read-Only Memory (PROM) Configuration Programmable read-only memories (PROMS) are classed as program PROMS or data PROMS.
Program PROMS contain code and data constants (designated " configuration data") that define the system design and configitration. Data PROMS contain data constants (designated " calibration data")
that are not necessarily fixed by the system design and configuration, but that may be initialized within specific ranges of values.
Program code and configuration data reside in read-only memories that are alterable only outside the j
system. If a processor contains only calibration data that does not need to be changed on a routine basis, the data PROMS are read-only memories that are alterable only outside the system, and may or i
may not be separate devices from the program PROMS. Where a processor contains calibration data i
and fixed data that may change routinely, the data PROMS are electrically erasable programmable
]
read-only memories (EEPROMs). [
l 1"
4 Revision: 0 June 27,1994 13
)
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description Any specific constraints on the use of various PROM types are identified in the systems requirements documentation. Any specific constraints on making calibration constants alterable by the user are also identified in the systems documentation.
I ju 3.2.5.2 RAM (Random Access Memory) Configuration Random access memory (RAM) contains interrupt vectors, program data, the stack, and allocated memory. Any excess RAM is considered to be free memory.
[
ja.c Interrupt vector locations are assigned absolutely by the CPU architecture. [
ju Program data uses RAM storage that is allocated to modules at compile time.
[
ju I
i ju 3.2.5.3 Static Data in RAM r
Where constants are stored in RAM, means are taken to prevent or detect unintentional alteration of the data. !
ju Other means that can be employed include:
g ju Revision: 0 June 27,1994 14
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Ir.strumentation and Control Software Architecture and Operation Description
[
y.c I
y.c
[
y.c
[
y.e I
y.e These means are employed at least to the extent necessary to support the minimum reliability requirements of the system Beyond that, they are employed to as great an extent as practical without conflicting with other system requirements (e.g. timing) and without conflicting with other software design principles, [
P*
3.2.6 Software Design Constraints Certain general constraints are imposed on the characteristics of software that provides an essential protection or control function.
3.2.6.1 Interrupts Interrupts are not used in the main functional procecsors that have direct protection or control functions. Special purpose processors (e.g. conununication or input scanning controllers) are permitted to use interrupts only if it can be demonstrated that their use is essential to the function -
being performed. [
y.e
[
y I
3.2.6.2 Concurrent Access
[
o Ja.c Revision: 0 June 27,1994 15
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 3.2.6.3 Multiple Processors Where multiple processing boards are used in a system, their execution is not mutually synchronized, except perhap:: during initialization. [
j..e in this context, " multiple processors" is taken to mean those which work together, each providing a l
separate processing function. This is distinct from " redundant processors", where each processor provides the same function, one as the back-up to the other. Processors which share access to resources do so in a way which, to the extent possible, does not allow a failure of one to prevent the others from continuing to operate normally.
3.2.6.4 Reentrancy
[
j.e i
3.2.6.5 Modularity l
Decomposition of functions into modules and procedures is done in a manner which promotes readability, functionality, portability, and manageability. [
j..e l
i 3.2.6.6 Procedure Structure I
j...
3.2.6.7 Data Bounding Data within the system is bounded to the range over which the software is specified to operate.
[
i
)
j..c The ability of hardware to produce only that data which lies within the expected range is confirmed
[
i j.e
-l Revision: 0 l
. June 27,1994 16
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 3.2.7 Application vs. Computer System Software A large portion of the Common Functions software can be thought of as. Computer System' rather than ' Application' software. [
j..c Application Software, on the other hand, is kept simple and straightforward. [
j..c 3.3 Software Documentation WCAP-13383, "AP600 Instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report," (Ref. 6.1-2), identifies the Software Design Requirements document and the Software Design Specification document as the proper place for documenting, respectively, the requirements and the design of the software that is developed by the top-down approach.
~
[
)..c
[
i
.,C
[
l Ja.c j
i Revision: 0 June 27,1994 17
)
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 4.0 Software Description 4.1 Software Architecture Overview The software functions which are used in the AP600 protection system can be classified as the following different types:
[
)=.c
[
ja.c
[
]=.c
[
ja.c
[
]=.c
[
)..c The relationships between the different software types in a subsystem are illustrated in figure 4.1.
These different software types are arranged in figure 4.1 according to the level of standardization achieved within each software type. [
j..c
['
ja.c I
ja.c Revision: 0 June 27,1994 18
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
[
..C I
j...
[
j..c
[
ja.c
[-
)..
I j.
Revision: 0 June 27,1994 19
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
[
ja.c
[
)..c i
}..c I
i Revision: 0 June 27,1994 20
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation
~
Description t
a,c I
Ja.c
[
i 1
ja.c
[
I Ja.c
' Bitbus is a trademark of the Intel Corporation.
Revision: 0 June 27,1994 21
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description I
j...
I J..c I
j...
f
~
3
?
Revision: 0 June 27,1994 22
= - -.
1 WESTLNGHOUS2 NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description l
4.2 Subsystem Functional Processor Loop Execution Sequence Figure 4.2 illustrates the execution sequence for a typical functional (host) processor. [
)...
The following items define each block of Figure 4.2:
[
3..
l
[
ja.
I i
]a,C j
[
)...
I ja.c
[
j...
I
}
Revision: 0 June 27,1994 23
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
[
j..c I
)..e
[
l
l
[
j..c l
j.
I j...
[
i j...
[
)..c Revision: 0 June 27,1994 24 i
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 4.3 Organization of the Software Functions in a Typical Subsystem The organization of the software functions in a typical subsystem is represented in the Subsystem Level Data Flow '.4:c un, Figure 4.3a and the Subsystem Level Control Flow Diagram, Figure 4.3b.
While these figures ce :vpical of subsystems in the AP600 Protection and Safety Monitoring System, they do not represe. 2 m.f specific subsystem architecture, rather they are a composite used for illustration purposes only. The subsystem level data flow diagram identifies the data that are passed between specific software functions along with the direction of the flow. The subsystem level data flow diagram which is shown here identifies the data only in general terms. The control flow diagram displays at the subsystem level which software functions are invoked by other software functions.
i I
s Ju I
f i
i Ju I
C t
L F
t ju The software functions that are shown in the data flow diagram and the hierarchy diagram are classified as the following different types
[
ju
[
ju Revision: 0 June 27,1994 25 l
f WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation
~
Description
-l
[
j..e
[
j..c
[
ja.c 1
Crosshatching is used in the diagrams to identify the classification of specific software functions.
i I
l l
i j..c i
[
j..e
[
f Ja.c 4
1
[
).c l
i j..e Revision: 0 l
June 27,1994 26
WESTINGIIOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
[
j...
I
).c I
8,C
[
I Revision: 0 June 27,1994 27
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
.,C
[
j..e
[
)
1 i
ja..
l
[
[
i Revision: 0 l
June 27,' 1994 28
WESTINGHOUSE NONPROPRIETARY CLASS 3
- AP600 Instrumentation and Control Software Architecture and Operation Description C
y.c i
I
[
p.c I
Ja.c l
i e
Revision: 0 June 27,1994 29
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description
[
jc
[
l
~
j
[
l l
)..e I
)..c i
Revision: 0 June 27,1994 30
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description J
l
[
i
)
j..e I
ja.c
-I j..e
[
j.
Revision: 0 June 27,1994 31
WESTINGHOUSE NONPROPRIETARY CLASS 3 i
AP600 Instrumentation and Control Software Architecture and Operation Descripf. ion l
8,C I
y.c J
~
Revision: 0 j
June 27,' 1994 3;
WESTINGHOUSE NONPROPR.IETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 4.4 Subsystem Level Data and Control Flow During the Execution Sequence Figures 4.3a and 4.3b present the overall subsystem level data flow and control flow for the entire subsystem functional processor loop execution sequence. These figures have been slightly simplified 4
to improve clarity. Several low-level utility functions that are called by [
]**have been omitted, as has [
]'* initializing various configuration and calibration tables during the initialization process.
Figures 4.4a & 4.4b through 4.11a & 4.llb present the subsystem level data flow and the subsystem level control flow during the individual subsystem functional processor loop execution sequence steps shown in figure 4.2.
[
y,e Figures 4.4a and 4.4b show the subsystem leve! data flow and subsystem level control flow
[
p.e Figures 4.5a and 4.5b show the subsystem level data flow and subsystem level control flow I
y.e Figures 4.6a and 4.6b show the subsystem level data flow and subsystem level control flow I
y.e i
Figures 4.7a and 4.7b show the subsystem level data flow and subsystem level control flow l
I p.e Figuies 4.8a and 4.8b show the subsystem level data flow and subsystem level control flow
[
Revision: 0 June 27,1994 33 i
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 4
y.c Figures 4.9a and 4.9b show the subsystem level data flow and subsystem level control flow
[
y.c Figures 4.10a and 4.10b show the subsystem level data flow and subsystem level control flow
[
l i
ja.c Figures 4.lla and 4. lib show the subsystem level data flow and subsystem level control flow
[
y.e i
1 i
Revision: 0 June 27,1994 34 j
WESTINGHOUSE NONPROPRIETARY CLASS 3 9.c, i
l l
l l
FIGURE 4.1 - SOFTWARE ARCHITECTURE OVERVIEW FILE: SWARCHN.DRW Revision 0
- 8 M W 35 June 27,1994 L
WESTINGHOUSE NONPROPRIETARY C' DSS 3
..e
't
?
I I
l l
l-4 4
i M
FIGURE 4.2 - TYPICAL FUNCTIONAL PROCESSOR FLOW DIAGRAM Revision 0 FILE: FP_ FLOWN.DRW June 27,1994 36 aae ous3w
WESTINGHOUSE NONPROPRIETARY CLASS 3 s*
l 1
1 l
I FIGURE 4.3a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM ru sec=om xemum Revision 0 June 27,1994 37 u
WESTINGHOUSE NONPROPRIETARY CLASS 3 se FIGURE 4.3b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM, a ssecmoaw a ma.
Revision 0 June 27,1994 38
WESTINGHOUSE NONPROPRIETARY CLASS 3
- e FIGURE 4.4a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM
(
)"
mo osaw Revision 0 June 27,1994 39
WESTINGHOUSE NONPROPRIETARY CLASS 3 u
i l
1 l
l l
l l
l l.
FIGURE 4.4b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FLE 88CONTW1 DRW 3u Flevision 0 June 27,1994 40
WESTINGHOUSE NONPROPRIETARY CLASS 3 a'
h D
i i
i FIGURE 4.5a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM
[
j'*
.wo es,xw Revision 0 June 27,1994 41 i
)
U1 WESTINGHOUSE NONPROPRIETARY CLASS 3 u
5 r
l i
i I
FIGURE 4.50 - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM
'.' L"**"
J
[
j" Revisen 0 j
June 27,1994 42
WESTINGHOUSE NONPROPRIETARY CLAS3 3 u
i FIGURE 4.6a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM Revision 0 June 27,1994 43
i WESTINGHOUSE NONPROPRIETARY CLASS 3 1
l 5
b I
I i
M%
FIGURE 4.6b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE SSCONTN2 DRW Revision 0 June 27,1994 44
i WESTINGHOUSE NONPROPRIETARY CLASS 3 u
i FIGURE 4.7a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM 1"ff""
a
[
j Revision 0 June 27,1994 45
i WESTINGHOUSE NONPROPRIETARY CLASS 3 l
1 E
FIGURE 4.7b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM Revision 0 June 27,1994 46
WESTINGHOUSE NONPROPRIETARY CLASS 3 FIGURE 4.8a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM Revision 0 June 27,1994 47
WESTINGHOUSE NONPROPRIETARY CLASS 3 u
r l
l FIGURE 4.8b-SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM i
eu wwww
[
ju Revision 0 June 27,1994 5
48 i
WESTINGHOUSE NONPROPRIETARY CLASS 3 se t
)
l l
i 1
i d
l FIGURE 4.9a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM Revision 0 June 27,1994 49 l
I
WESTINGHOUSE NONPROPRIETARY CLASS 3 FIGURE 4.9b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM
[
)*'
LYdd* w"""
Revision 0 June 27,1994 50
WESTINGHOUSE NONPROPRIETARY CLASS 3 u
t d
7 FIGURE 4.10a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FRE BSDATAN7.DRW Revision 0 j
June 27,1994 51
WESTINGHOUSE NONPROT RIETARY CLASS 3 8'
t I
FIGURE 4.10b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM re.a esecwwonw
[
)*'
as osa+w Revision 0 June 27,1994 52
WESTINGHOUSE NONPROPRIETARY CLASS 3 u
i 1
1 i
i l
l FIGURE 4.11a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FR.E SSDATANO DRW q
[
ju
,us osou Revision 0 June 27,1994 53 I
i WESTINGHOUSE NONPROPRIETARY CLASS 3 u
.t I
i l
)
i FIGURE 4.11b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM
')
FLE. SSCONTN8 DRW I
Revision 0 June 27.1994 i
54
F
- W==..
Z Ud M
U)
CD 50
>-C<
b_
_Z Q.
Oc Q.
ZO Z
UJ (o
3OzO ZF Co LU$
i 1
l i
H i
b r^
i
c ho 4
W to
- O co 01 W
4 O
w w
>ir
- n >
oo
, ~
.i
(, '
40a <,
ea
_. ; u-Et.!:
- "?
i ~"!
s>
.,, c, qif o rf t
ra ai o cl. o p;
a FIGURE 4.3a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM ru:ssoumonw us osam4 Revision 0 June 27,1994 37 s
r b
m
.,,, ~,.....,.,. _.,,.,.. -.. _,.. - - _ _., _, _,...
_.,_,_,m.
. __. _;j
F' MM MM k
o.
I e
i 1
M (o
50
>-T<
b
_C Q.
OC D.Z OZ W
CD D
OI OZ P
M uJN
=
l A cO L'
eo h
o 4
w to o
eo en w
IoN 7
y.
.[
t u:
FIGURE 4.3b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM ressecumonw JJB 05'2494 Revision 0 June 27,1994 38 f,
-7.~~.
E oW CD 50>C
<C ba CL Oc CLZOZW CDD O
I OZs (OW3
l co 4
o N
w i
IC o
co m
w I
O.
V
> w,.
s 4 E; u>
q>
0 a z.
a a;
- , ~; m*
~.._~4, a -.
-=
g C Cf
" ** [Ij r
La G
? nn
.j ' "
ci FIGURE 4.4a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FILE: SSDATAN1.DRW a,c
(
JJB 05/24/94 i
Revision 0 4
June 27,1994 39 4
OW HM d
n O
M
$0>c<
ba Q.
OC n.Z OzW u)
D O
"C0Zs 0)
e k
o
- Q w
w o
e e.n
)O 2
so
. n; >
.3
.Y N
c~
-),
,;,. 7
. - 3 U,-)
=
2 FIGURE 4.4b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN1.DRW
{
}a,c JJB 05/24/94 Revision 0 June 27,1994 40 4.
I
j i
ki WESTINGHOUSE NONPROPRIETARY CLASS 3 a.c v
e k
o 4
w to
- o cc en w
i
\\
7,
),-
v sm es 5 :.
, -1 c.._
. i41
.=' u
. O
~~ s i;;
FIGURE 4.Sa - SUBSYSTEM LEVEL DATA FLOW DIAGRAM
- _omo,
]**
x s osa 4/94 Revirion 0 June 27,1994 41
f"
- ei e** =wa d
qn O
m CO 50>C<
b__
C Q.
O C
0.ZOz l
W m
D O1 O
1 ZF CO W3 l
l 1
i l
l l
om mares
C k
o 4
W M
o CO C.R W
IOe w
)f ['{
Tli s,
{~j '
iQ.
e, 7"f.'
m --
's
~~0 ii!
FIGURE 4.5b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN2.DRW
}"#
xs os/24/94 Revision 0 June 27,1994 42 4
4
O f*
M$
n M
U) 50>W<
ba 0.
Om Q.Z OZ i
W U)
D O
i l
@+o N
>-a to o
w en 1
l o
J
@2
~~ >
,8 a, >
p 7,
%.!. Q,l f. n-
., e O [j-J,,' ~{ d
- *~ : T a c.-
.t
. J; !,3
' ~
e ;;:.-
g
- s. u a
2 FIGURE 4.6a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FILE: SSDATAN3.DRW
[
]*c neovams Revision 0 June 27,1994 43 6
i
E i
M CO 1
t 5o>C
_C CL O
C CLZ
{
O z
l W
l 1
(O D
Ox0z
(
(n W3 I
-1 I
=
l i
-MN MM i
C 4
o aJ w
. O to 01 w
6 CP-2 A
s 9., '.:
n-
- ~,
Q: -
.3 c:
c d[
~i
=
tr>
FIGURE 4.6b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM __,,
Revision 0 June 27,1994 44
?
k
}
=
0, 8
M
\\
(f)
U) o 1
1 b._
C D.
O I
E l
1 MM L.
cou o
4
.too ca en w
io D
4 d
> cr s
ca ny o.
n
? a,d, k<;
3 "l C D'
'"r! e,3 3
ms y/
o.{,.{J
[,(j..,.j C
c-
~' ::.~ o*m w o a0 u
i a
m i
i FIGURE 4.7a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FLE: SSDATAN4.DRW JJB 06/24/94 Revision 0 June 27,1994 i
}
?
L
'--~..... -. -
.L
.. L..
."L..::1-.'l--.
v
,m.- - - -, <.
.--.~,a,.
..e.---
-,..en--.-.
--mn~m wm.
.-a, r-
~-.-
s
.r=~
a+ 'w.e e.. w-me e,u
, - ~ -
e
F the esu88 man om f
U.
15 f
MW CD
$0
>-C
_1c.
Oc 0.2 OZW (ODO1O ZI CDW3
- ~. _ -
CO b
o 4
W D
'o CO CR
>=*
\\
w@
> -- 3,.
?a ti oo
- 1' l,_.:
i-; s.
f) ;'
[-' <
b) -
1
,f N[?b b,
[, O r
FIGURE 4.7b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN4.DRW
(
) a,c JJB 05/24/94 Revision 0 June 27,1994 46 1
}
an some. we m e
Z co CO CD 50>1<
ba Q.
O 1n.Z O
Z W
(0DOI OZ P
CO W3 w
-~
l 1
en o
4 w
N
- o co en w
I=
@!i a>
E>
O ra z 5B
> ;D O)
- e. =
m.a._ >
o s 6 d ul o
n ma "8
rn FIGURE 4.8a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FILE: SSDATANS.DRW Revision 0 June 27,1994 47 1
T'
.# - =
M M
m 5
O C<
ba D.Om n.
Z O
Z W
MD O
1 O
i CO k
O I
I W
lO
~C CO Cl1 W
i
>P rd O>
E>
C !*il 2 i$d
?> :.Z.1 (I) o ;u
- 77)..,._{
fI tTi C iTI
?-
a
- 33 O Cu a
,,{
a i?
FIGURE 4.8b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTNS.DRW
{
JJB 05/24/94 Revision 0 June 27,1994 48 i
s 4
g M
9 o.W (O
(D 50
>-C
- C b
_E CL Oc 0.2 Oz W
to DO I
OzI to W3
=
- Nesp ous
e o
4 W
l to
-o co en w
I Q
- ii a>
2 C ra Z E[>
In :*:! w 5
cs,
- -:.4 o&
- , c3 o rn
~5 9"35 8
m FIGURE 4.9a - SUB5YSTEM LEVEL DATA FLOW DIAGRAM FK.E: SSDATAN6.DRW Revision 0 June 27,1994 49 a
1:
e i'
EJ C.a 3
PN ON ESU O
H G
NI TSEW ei Is f!IIt ii!lt Ilf IiIl,IlIIllllt
k O
4 W
D o
CO C1 W
l
-E 7>
gu
_o j_ l'
~.V:
v')
-f
-... il
- U
- l'!
FIGURE 4.9b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN6.DRW
[
]a,c JJB 05/24/94 Revision 0 June 27,1994 50 i
n i
4-)
J e
OWMO u
Ud CO CO (o
50>C b<
_C Q.
Oct Q.ZO Z
W CO 3
O I
OZ P
CO W
1 i
i l
i l
l 1
l i
,=
e
co k
o 4
w M
o co en w
I
-M 4, 2 8
TJ >
e :.
O rn Z El *:,
',' 10 {/)
.C -
1
? -
- - _j _4 e< _
- t. ; L;;; mO g
- n FIGURE 4.10a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FILE: SSDATAN7.DRW Revision 0 June 27,1994 9
51 4
3.
l i
M M
s M
(O CD
$0>C<
b Q.
O E
Q.
Z O
Z W
(D 3O 10Z (O
W3 i
i G
4 D% WIB M
I C
A o
4 W
M
'o CO CJ1 W
I D
>y b
tO M ',b 5>
O Ifl 2' Es JW A:
c ;u
,y - -3._.;
PE OCm d
- 0 0 a o 1!I 1
FIGURE 4.10b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN7.DRW
(
JJB 05/24/94 I
Revision 0 June 27,1994 1
52 i
a 4
-m.
y
paph 4
.-$h Ud O
CD 50>C
<C b
_C 0.
O Cc.
Z Oz W
CO DO I
O Z
P CD 1
W N
en l
i W
m==.
ae i
~
e bo 4
w to o
co en w
I
-J n,
,$> s}'
'1 s
C.
i
~
~
j FIGURE 4.11a - SUBSYSTEM LEVEL DATA FLOW DIAGRAM FILE: SSDATAN8.DRW Revision 0 June 27,1994 53 i
4 k
m..
.m
.2_,-,-.
_4,,,,
r
.--,-~...,___.__.e
-w-s,
p-
@V **
N O.
86 a
M U) 50>Z<
b_
C Q.
Oc 0.ZO Z
Lij U)
DO IO ZF U)
LU3 l
i I
i esm+
w
to A
O
- Q M
o CO Ca w
I
> c5 Ja 7 lb 7[t [i" O m ~Z 0
.s ': in
.% t ;
a i=
.' :::.L) c tr g ::. -.-
- t. ;
- c. o:s m
FIGURE 4.11b - SUBSYSTEM LEVEL CONTROL FLOW DIAGRAM FILE: SSCONTN8.DRW b
)
JJB 05/24/94 Revision 0 June 27,1994 54 n
f t
L i
I WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 4
5.0 Software Testing and Ver:fication The complete design, verification, and validation process for the AP600 instrumentation and control hardware and software is described in WCAP-13383, "AP600 Instrumentation and Control Hardware and Software Design, Verification, and Validation Process Report", (Ref. 6.1-2). The AP600 software verification process is integrated into the overall system design, verification, and validation process. Section 3.0 of WCAP-13383 includes descriptions of the documents produced as part of the design, verification, and validation process that are specific to the software part of the instrumentation and control system.
The software design philosophy described in section 3.0 of this report stresses a " Design for Verification" approach throughout the software design and system integration aspects of the instrumentation and control. For software modules, this concept requires that software module design methods provide features so that the resulting design is immediately verifiable by independent review, that software modules contain sufficient test features to support verification testing and are able to be readily tested to verify that design requirements are met, and that the test results are useable.
In addition to the software verification portion of the process, proper function of the software is also verified and validated by the overall system verification and validation portion of the design, verification, and validation process.
5.1 Software Testing Strategy and Methodology The testing methodology utilizes a formalized systematic approach:
[
p.c
[
p.c
[
p.c
[
p.c I
y.e
[
t y.e Revision: 0 June 27,1994 55
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description Westinghouse uses both manual and automated methods of verifying software.
The manual methods include:
[
]= c I
ja.e The automated methods include:
[
]* c
[
]' c
[
j.e
[
]*.c 5.2 Software Design and Verification Documentation The software design and development process follows a top-down approach of a progressive and systematic breakdown of the requirements into detail, and the definition of these requirements by a structured set of documents of pre-defined scope and contents. This is reflected by the documentation for each software module as described in WCAP-13383 (Ref. 6.1-2):
a l
3..e I
ji.e i
ja.c l
j.e I.
2 Numbers are sections in WCAP-13383 (Ref 6.1-2) 1 Revision: 0 June 27,1994 56 i
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation
-Description
).
[
3..e I
a,C These software documents contain sufficient information for a third party to repeat the software tests and understand the results.
t i
Revision: 0 June 27,1994 57
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 6.0 References The following lists contain reference documents, guidelines, codes and standards which are applicable, in whole or in part, to the design of the AP600 software. This list is for reference only.
The revision level of the documents is controlled by the System Specification Document described in WCAP-13383. System design requirements have been established to meet the requirements and guidance of the references listed.
6.1 Westinghouse Documents 6.1-1 WCAP-13382 AP600 instrumentation and Control liardware Description (AP600 Document Number GW-JJ-001) 6.1-2 WCAP-13383 AP600 Instrumentation and Control 11ardware and Software Design, Verification, and Validation Process Report (AP600 Document GW-J1R-002) 6.1-3 C&PGSTD-001 System Development / Implementation Process (SYSDlP) 6.1-4 C&PGSTD-005 Configuration Management Practices 6.1-5 C&PGSTD-100 Software Design and Coding Standards i
6.1-6 C&PGSTD-100 PLD Software Design and Coding Standards 6.1-7 SXB-WN-705138/7 W-ISCO Principles of Design 6.1-8 SXB-RP-705195/8 W-ISCO DataMaster Requirements and Description 6.2 Standards 6.2-1 ANSI /IEEE Std 100 IEEE Standard Dictionary of Electrical and Electronic Terms
.l l
6.2-2 ANSI /IEEE Std 729 IEEE Standard Glossary of Software Engineering Terminology 6.2-3 ANSI /IEEE Std 730 IEEE Standard for Software Quality Assurance Plans 6.2-4 IEEE/ ANSI 802.3 Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Bus Access Method (Process Bus / Logic Bus) 6.2-5 IEEE Std 828 IEEE Standard for Software Configuration Management Plans Revision: 0 June 27,1994 58 l
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description 6.2-6 ANSI /IEEE Std 829 IEEE Standard for Software Test Documentation 6.2-7 ANSI /IEEE-ANS-7-4.3.2 American National Standard Application Criteria for Programmable Digital Computer Systems in Safety Systems of Nuclear Power Generating Stations 6.2-8 IEEE Std 1012 Standard for Software Verification and Validation Plans 6.2-9 IEC 880 Software for Computers in the Safety Systems of Nuclear Power Stations 6.2-10 RS-232-C Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange 6.2-11 RS-422-A Electrical Characteristics of Balanced Voltage Digital Interface Circuits 6.2-12 EIA-485 Standard for Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems 6.2-13 ISO 3309 Data Communications - High Level Datalink Control Procedures - Frame Structure 6.2-14 ISO 4335 Data Conununications - High Level Datalink Control Procedures - Elements of Procedures, Appendix 1 6.2-15 ANSI X3.166 Physical Layer Medium Dependent (PMD) 6.2-16 ANSI X3.184 Single-Mode Fiber Physical Layer Medium Dependent (SMF-1 PMD) 6.2-17 ANSI X3.148 Physical Layer Protocol (PHY) l 6.2-18 ANSI X3.139 Media Access Control (MAC) 6.:2-19 ANSI X3T9.5/88-139 Media Access Control (MAC-M) (Maintenance Revision) 6.2-20 ANSI X3T9.5/84-49 Station Management (SMT) 4 Revision: 0 June 27,1994 59
WESTINGHOUSE NONPROPRIETARY CLASS 3 AP600 Instrumentation and Control Software Architecture and Operation Description j.
6.3 Technical Papers l
6.3-1
" Diagnostic Software and Hardware for Critical Real-Time Systems", M. D. Bowers etal, IEEE Transactions on Nuclear Science; 1988 Nuclear Science Symposium 6.3-2 "Multiprocessor Shared-Memory Information Exchange", L. L. Santoline et al, IEEE Transactions on Nuclear Science; 1988 Nuclear Science Symposium i
d 9
Revision: 0 June 27,1994 60
. _ _.