ML20203K713
| ML20203K713 | |
| Person / Time | |
|---|---|
| Site: | San Onofre  |
| Issue date: | 04/03/1996 |
| From: | Edelman M, Leon J, Lopez S SOUTHERN CALIFORNIA EDISON CO. |
| To: | |
| Shared Package | |
| ML20203K553 | List: |
| References | |
| S0123-606-1-10, S0123-606-1-10-1-R01, S123-606-1-10, S123-606-1-10-1-R1, NUDOCS 9803050208 | |
| Download: ML20203K713 (105) | |
Text
_ _ _ _ _ _
I
.J t
t I
i I .
i i
I- ;
i i
t e i
.i l ENCLOSURE 3 I
SYSTEM SOFTWARE REQUIREMENTS SPECIFICATIONS i !
! I (Also: DCN' ABG 11366)
I
'E f
4 i
?
f.
l 4
4 d
4 b
i a
h e
i t
1
+
. 9903050208 990302-
... _ . _ _ _.._.._;..._.~..-~. . _ , ..._.___.__..:.._.__.___ _ _ _ . _ . , _ . . _ _ . _ _ _ _ , . . . . _ . . . . _ _ _ _ _ . . - ,
l PoooossA. ooc PGD-00099 Revision 1
,l . .,
. . q February 16,1995 ,
, t ,,. al aJ l
SYSTEM SOFTWARE REQUIREMENTS gg SPECIFICATIONS APR 151996 SHEflLE00PY Prepared by: Reviewed by: Approved by:
Name Mike Edelman Sergio Lopez Joe Leon Date g j.- g J-/p -f f g -g 4,6 De, Mr.v-- I Signature .
/ .
'# L..
I VPL H f 5** h l)h "/*~/f) ~ f- .
E 1. APP'ROYED Mig.rnay proceed.MV. / lM N@
O . MPRgEXCEPT AS NOTED - Make changes and resutmL utg.
O 3. OT ROVED - Conect and resdwntt for review. Not to be used for O 4. REFERENCE 00CUMENT = 'Wormaton Ordf CAUFORKW EDlSoN COMPANY {yNp MS *' we ' m FM4""
a
'1l*U' ""R*$"tsrr,"a h i nI .
)
ni
. fe g .
" "F"*' e 7 put ClasslEcanon Ref.o . w pus
- Du vOTHEReses p w d E MA M I m;. . un INSTRUMEini ""- -"~"---
Suite 150 --
5000 Highlands Parkway Smyrna, GA 30082 AR information in this document is the exclusive property o' MOP Instruments, Inc and is not to be disclosed. reproduced, or used except as authortzed in writing t*y MGP instruments. inc.
j
PCD 00099 / REVISION 1 PGD0099A. DOC PCge + ll +
REVISION LOG:
Revision # Date Revised Pages Comments 0 8/11/95 N/A Originalissue 1 2/16/96 Appendix A Update Appendix A All information in this document is the esclusive property of MGP instruments, Inc. and is not to be disclosed, reproduced lor used except as authortred in wntog by MGP instruments, Inc.
---__ U
PGD 00099 / REVISION 1 roooonA. ooc Page . lli .
TABLE OF CONTENTS Page Attachment A - System Software Requirements Specifications MG)
Doc ume nt #4517 9C A ...... ..... . ........... ...... . ........... ..... ... . .... ....... ... .... . .. ... 1 AR information in this document is the exclus#ve property of MGP instruments, Inc. and is not to be disclosed, reproduced, or used except as cuthortred in writing by MGP instruments, Inc.
i >
. MG..P, Radiation Monitorin9 System r ,
4.A!.
C.i ,
1 1
System Software Requirements l Specif.ications
! Written by: J.Nadaud Date: 16/11/93 Visa:
l Checked by: A. Pommier Date: 10/03/94 Visa:
l Approved by: L. Meslay Date: J0/03/94 Visa:
INTERNAL DISPATCHING EXTERNAL DISPATCHING F. Schulcz A. Pommier MGP instruments Inc.
F. Chiosta J.P. Guillemot J.Nadaud D. Canessa P. Stolpe Number of pages : 58
"" C" " C"'**
C 30/01/96 MGPl inc Comments End of prototype cycle "" * ""'" C"S**
B 25/04/95 A 10/03/94 Onginal edition Wnter Checker Approb Ind. Date Modificadon number & designadon M.F. '
Signatures L*OTO"O"","OT.0%*IL".7.#,L~4',".470"%"~:1. - 45179 cA
n-ll Radiation Monitoring System System Software Requirements Specifications p2 Update Table Index /Date Modified pages Origin and designation of the modification Written by '
8 21,22 Added measurement output managemen 2f/494 chapter, J,Nadsud 24 Degraded mode conditions have changed.
32 Added output commend screen on DU.
51 Removed DU screens (redundant with DU' SRS).
57 Improved schematic.
78 79 Updated algorithm table.
8 All pages. Modifications according to MGPl in 31MTM5 cumments.
L.8sttini C 12/7/95 NAJ Appendix B & C Removed unit and algorithm table (redundant with LPU Parameter Table) 7 9.11 13,17,25.30,35 Implement SCE comments dated 1012 95 L%T2.*,.7,L*,, : .M==2:LK. s-. 45179 cA
MiMGP d apaym Radiation Moniton'ng System System Software Requirements Specircahone p3 Table o content
- 1. I n t r od u cti o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Purpose.....................................................................................................6 1.2. Scope...........................................................................................................7 1.3. Definitions, Actonyms and Abbreviations........ ................... ....................... .. 8
- 1. 4 . R e f e r e n ce s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Overview...................................................................................................9
- 2. G e n e ral D e s cription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Prod u ct Pe rs pective s . . . . . . . .. . . . .. ... . .. . .. .. .... ... . . .. . . . .. .. . . . . . . . . . . . . . ...............10
- 2. 2. P rod u ct F u n ction s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 2. 3. U s e r C h a ra ete ristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2. 4. G e n e ral C o n s t raint s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. As su mptions a nd De pe nd e nele s.. ... . ..... . .. .. .. .. ... ..... . . . .. .... .. ...... .. .. . . . . . . . .. ... . . . . 12
- 3. S pe cific R e q uire m e nt s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. F u nctional req uirem e nts . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Resident communication requirements...... ...... ....................... .....13 3.1.1.1. I nt.~od u cti o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 3.1.1. 2. I n p u t s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. 3. P roce s s i n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 .1.1. 4 . O ut p u t s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5 4
3.1.2. DU system function requirements................................ ................... 15 3.1.2.1. I ntrod u ctio n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 . 2. 2. I n p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6 3.1. 2. 3. Pro ce s s i n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. 2. 4 . O ut p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.3. LPU system function requirements ... .......... .. ............................... 17 3.1. 3.1. I ntrod u ctio n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. 3 . 2. I n p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7 3.1. 3. 3. Proce s si n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3 .1. 3. 4 . O u t p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 3.1.4. Measurement output management............. ............ ............ .......... 18 3.1. 4.1. I ntrod u ctio n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. 4 . 2. I n p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 3.1. 4. 3. Proce s sing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 .1. 4.4. O utput s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .............19 3.1.5. Operation modes ... ............ ... . . ..... . . . . . . ....................20 3.1.5.1. I ntrod uction . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 20 3.1. 5.2. I n puts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ........................20 3.1. 5. 3. Proce s sin g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 0 3.1.5.3.1. Normal operation ...... . ...................20 t
3.1.5.3.2. Maintenance mode . . . . . . . . . . .. 20 3.1.5.3.3. Degraded mode. . .. . . . . . . . . . .. 21 3.1. 5.4. O ut put s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ... .. 21 3.1.6. Monitor with multiple detectors .. . .. . . . . .. . .. . . . .. . .. . 22
- w. - ,.m,.-m ,,.,w.,.%
..,w-..um...~,-.. . .m, e "
45179 CA
% ..- . m.w ,,,
$t)MGP nep m Radiation Moniton~ng System System Software Reawements Specifications p4 3.1.6.1. I ntrod u ction . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .............22 3.1. 6. 2. I n put s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3.1.6. 3. Proce ssing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1. 6 . 4. O ut p uts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3.1.7. C om m a nd m a na g e me nt . . . .. .. . ... . . . . . ....... . . . . . . . . .. . . . . . . . . . . . . . . 2 3 3.1.7.1. I nt rod u ctio n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................23 3.1. 7 . 2 . I n p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 3.1. 7. 3. P roce s sin g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 3.1.7.3.1. Command manogement ..................................... 23 3.1.7.3.2. Digital input command association........... .......... 25 3.1.7.3.3. Output emulation mode.............. .. .. . ..... .......... 26 3.1.7.3.4. Program downloading process............... . . . ...... 28 3.1. 7. 4 . O u t p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 9 3.1.8. I n put/ Output man a ge me nt .. . .......... ...... .... . ....... .... . . .. . . ,. . . . . .. . . . .. . . . . . .. . . 2 9 3.1. 8.1. I nt rod u cti o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :. 2 9 3 .1. 8. 2. I n p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 9 3.1. 8. 3. Proce s si n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 0 3.1.8.3.1. Outpu t m ana gem e nt ....... ... .... . . .. . . . ... ..... .. . . .... . .. ... 30 3.1.8.3.2. Automatic output command mode on DU ........... 31 3.1.8.3.3. . Exported digital input and internal flags ............ 33 3.1.8.3.4. Exported analog input management ...... .... ....... 34 3.1.8.3.6. Exported measurement management... . ........... 34 3.1.8.3.6. PING parameter setup example.......................... 34 3.1. 8 . 4 . O ut p ut s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5
- 3. 2. E xt e m al I nt e rf a ce s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6
- 3. 2.1. U s e r I nt e rf a ce s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 3.2.1.1. LP U us er int e rf a ce s... . . ... .. . . ......... . .. . . . . . ..... . . .... ... ... . . . . ... . . . 36 3.2.1. 2. DU use r int e rf a ce s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.1.2.1. Local display unit interface.... ................. ........... 36 3.2.1.2.2. Remote display unit interface. .................. ...... .. 37
- 3. 2.2. H a rdwa re i nte rfa ce s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 7 3.2.2.1, M ODBU S/J B U S se rial link .. .. . .. . ...... . ... .... ... . . ... .. .. . ... .... . . . . . 37
- 3. 2.2.2. Prog ra m m e m o ry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 8
- 3. 2. 2. 3. D a t a m e m ory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 8 3.2.2.4. H ardwa re watchd og ..... .... .. .. . .... .. ... ... .. ... .. . . . . . . . . .. .. . . 3 9 3.2.2.5. Power supply monitoring ....................... . ...... .... ... ..... .. 39 3.2.3. Software Interfaces ................ ........... ... . ... . . . . . . . . . . . .........39 3.2.4. Communication hardware interfaces .... ....... . ....... . ... . . .. 39 3.3. Pe rform a nee Req uire m ents . ..... . ... . . ... .. .... . ......... . . . . .. . . ... .. . . . . . . . . . ... . . 4 0 3.3.1. Downstream communications link loading....... ............ . .. . . .. . . . 40 3.3.1.1, Maximum configuration.... . . . . . . . . . ..... ............41 3.3.1.2. PING configuration............ . . ....... . ... ..................41 3.3.2. CPU performanee . . .... . .. . . . . . ... .. . . . .. . . . . . . . . . . . . . . . . . . . ... 42
- 3. 3. 3. M e m o ry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....................42 3.4. De sig n Constraint s . ... .... . . . . . . . .. . . . . . . . .. . . . .... . . . . . . . .. . , . . . . . . . . . .. . . 42 3.4.1. Standards compliance.. . . . . . . . . . . . . . . . . ... .. . . . . .42 3.4.2. Hardware Limitations., .. .. .... .. .... . .. . . .. . . 42 n.~...-,.-n.,,.
e-.w .n .n.- .o.,.%. . , ,,. . 4 .~,w, . . ,,,,,m ".m". .u" .".".' ".".n" . .5m. . 45179 CA I
1
_ . _ _._. .._._, ._._._..._____._.m.__.. -
i
,I Radiation Monitoring System System Software Requirements Specificat6ons p6
- 3. 5. At t ri b u t e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 3. 5.1. S e cu rit y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
- 3. 5.1.1. Fa ult det e ction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 3.5.1.1.1.. Machine instruction level............................. ........ 43 3.5.1.1.2. Code module level ........... ...... ....... ... ............. ...... 4 3 ,
- 3. 5.1.1. 3. Aud it le vel . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . 44
- 3. 5.1.1.4. S y st e m levol . ... .. . . . . . . .. . .. . . . .. . .. .. . ... . . ... . . . . . ... . . . . . . .. . . . 4 5 APPE NDIX-A Standard pa remeter table ....... .... ................................... .......... ... .............. . 46 '
l i
i
- n. m. -..m.
% . - - w . %. -- m - . - ~ , ".'.". . % 45179 CA-
,,mm,,-wo-. , ., 7 ,w---- #mm..-. , ,.#r. w- ._.,n.c.,n..,v-.,-..- . . . , ,, m.c.-,-_.%,.7, , , -. - .. ~ .-- ,,-.v---- ,.w.-ever.i.ew-
$L_, Ra$ation Monitoring System katem Software Requirements Specifications p6
- 1. Introduction 1.1. Purpose This document describes the interaction of the RMS devices when they are connected together. This is a system Software Requirement document that makes the link between the various Software Requirements Specifications (SRS) that are going to be generated for RMS units. It concerns and focuses mainly on network link specifications and on Inter unit data flow.
This document complements the other SRS. It further promotes:
- 1. Software customers to understand exactly what the supplier provides.
- 2. Software supplier to accurately describe what the design entails.
This SRS shall accomplish the following goals:
. Establish the basis for agreement between the customers and the supplier on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential user, to determine if the software specified meets their needs or how the software must be modified to meet their needs.
. Reduce the development effort by considering all the requirements before design begins.
. Provide a basis for estimating costs and schedules. The requirements which, together with a development plan, can be used to measure progress.
- Facilitate transfer. The SRS makes it easier to transfer the software product to new users.
. Serves as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be modified, but it does provide a solid foundation for continued production evolution. ,
1 M%"C % C O740;O7,L" C L~n.LTO!!Cn. sm. 45179 CA
- . - - ~ .. ._ - .. ... - .- .. - . - - - . - . - _ -- - - . . - - - - - . - .- . . . - _
l
[ Radiation Monttonng System System Software Requirement 6 Specifications p7 1.2. Scope This SRS concerns tSe following devices of the Radiation Monitoring System project:
LPU Localprocessing units l LPU SI Silicon detector ambient dose rate monitor (Iow and high range). )
l LPUlC Area monitor with lonizadon. chamber (Ambient end accident conditions). l LPU P/PS Alpha / Beta particulate or gas monitor with Gamma compensation.
LPU SAS
)
Process or Effluent radiation monitor with multichannel analyzer system, t i LPUlo Unit that converts analog and / or digital input signals into RMS '
compatible measurements.
DU Displayunits 1
LCU Local Control Unit to control a monitor without display and report. I LDU Local Display Unit to control a monitor and/or to report Information.
RDU Remote Display Unit to centralize information reporting in a cabinet.
SDU Simplified Display Unit to report information directly from LPUs.
Liquidand gas monitors PING Particulate, lodine and Noble gas continuous air monitor consisting of l sampling equipment, three LPUs subassemblies and an LDU.
SAP /G Spectrum Analysis Particulate, lodine and Noble gas monitor with Gamma measurement consisting of sampling equipment, two LPU SAS l and an.LDM.
Computers MASS Maintenance And Set up Software for Portable or desktop computer.
W 2 a~w,~ 3'7272; TOT &*"*?. ::u"~nw'% .o.m. 4S179 CA
--- - . . . _ . . _ - __ . ~ . _ _ _
1 M MGP f.ltesapmans Radiation Moniton'ng System i
System Software Requirements Specifications p8 1.3. Definitions, Acronyms and Abbreviations i l
AL Alert afarm threshold ANS American Nuclear Society ANSI American National Standrirds Institula kan Bit Per Second CM Measurement board \
CEM Counts Per Minute GRG Cyc!!c Redundancv Code \
CI Processing board (Carte de Traitement)
DAS Data Acouls! tion System DM DisDlay Unit ELASH Electrical erasable orogrammable read ontv memorv 8 High alarm threshold 88 High/High alarm threshold IQ 10Disallon Chamber ,
LEC Intemational Electrotechnical Commision lEEE Institute of Elecidcal and Electronics Engjagem to lodine floda)
It Irradiation JBUS Industrialdigitalnetwork from APRIL ,
LAN LQcal Area Network LAPTOP Portable comouter LQM Local Control Unit LDM Local DisDiav Unit LP_U LocalProcessina Unit MASS Maintenance And Setuo Software MQDBUS Industdal digital network from MODICON NQ Not Used P_blQ Pioing andInstrument Diagram PALMTOP Portable cQmputer that lits in the calm of hand P_Q Personnal Computer (IBM comoatible)
PJNG Particulate lodine and Noble Gas monitor PLES Passivated Imolanted Plannar Silicone SQU Remote Disolay Unit SMS Radiation Monitoring System SAPlG Spectrum Analysis Particulato lodine and noble Gas monitor SAS Spectrum Analvzcr Svstem SCADA Suoervisory Control and Data Acauisition SDM Simolified Disolev Unit El Silicon SRS Software Reauirements Soecifications E Y E T b ~m M %L* O C 1 ~ *a7.U Z 7 . m I45179 CA
gkennnnensMGP Radiation Monitoring System System Sofhvare Requirements Specifications p9 1.4. References (1) ANSiflEEE Std 7291983 IEEE Standard Glossary of Software Engineering Terminology.
(2) ANSillEEE Std 8301984 Guide to Software Requirements Specifications (3) lEC 8801986 IEC Standard for Software for computers in the safety systems of nuclearpower stations.
(4) MGP SOAP -45203 RMS Software Quality Assurance Plan (5) MGP.SWP 46120 RMS Software Verification and Validation Plan (6) MGP SDP 45202 RMS Software Development Plan (7) MGP GRS 45254 RMS GeneralRequirements Specification (8) MGP-Protocol ST - 45866 Embedded protocol technical specifications (9) MGP LPU.SRS .45180 General LPU Software Requirements Specification (10) MGP DU.SRS -45182 DU Software Requirements Specification 1.5. Overview This document, describes briefly the system functions, and then details the characteristics of all these functions, especially the interfaces with the user, the hardware and the other softwares. This document conforms to the guidlines of ANSI / IEEE 830-1984 [2]
M O 7".k Toeu.7"M E7.L*O** M O O Z O . s- 45179 CA l
___-______~
11 System Software Requirements Specifications Radiation Monitoring System p 10
- 2. General Description 2.1. Product Perspectives The purpose of the Radiation Monitoring System project is to provide nuclear power plant personnel with information concerning radiation levels in plant procese systems, effluent paths, and areas required to safely operate the plant and protect the surrounding environment. The RMS is designed to assist plant personnel in evaluating and controlling the radiological consequences of normal operation and postulated accidents that results in the release of radiation to uncontrolled areas. Radiation monitoring alarm signals are generated if preset radiation alarm set points are exceeded and plant safety system actuation signals are also initiated in required cases.
2.2. Product Functions The Radiation Monitoring System is able to acquire radiation Information from different kind of detectors. It displays this information locally, and centralizes all the measurements into a DAS system.
Here are the functions that the system will perform:
LPU functions (detector):
. Acquire a measurement from a detector, and generate a standard unit result.
. Detect increasing area radiation levels (dose rate, volumic activities).
. Memorize activity levels and events.
. Physical, electrical and virtual checkouts.
. Permanent self-checking and diagnosis functions
. Network communication with external command management DU functions (disclav unit):
. Provide alarms and level indications (sound, lights, analog recorders).
. Display measurements.
. Route sample flows, gas or liquid through a sampling assembly.
. Memorize events.
. Permanent self-checking and diagnosis functions
. Network cunmunication with extemal command management M 7E"7 C iO M .".7 O'C*O*%TOO.'."%'O no.s 45179 CA i
,a Radiation Moniton'ng System System Software Requirements Specifications p 11 MASS functions (maintenance system):
. Display unit variables.
. Display and modify unit parameters.
. Display graphical data (histograms, spectra...)
. Start physical, electrical and virtual checkouts.
. Program downloading process.
1 DAS functions (suoervisor) l This supervisory system that is not develooed by MGPl adds to the MASS software the following functions:
. Database display for the whole communication.
. P&lD display i . Generate, memorize and display real time historical trends
. Provide information up to the central computer.
All devices are connected together using digital networking capabilites. The system can l be decomposed into three levels:
M
, M c_ _N E
- w muww o^s O'
, DU Data Hohway l
1 LPU Deta Hghway !
i
<aza>
H3ZD>
r CIED l
M l
l ~
l b".*.lO7b"OOf' ".OdU.~= J ""# ~a.n*i O."EL**ew sm. 45179 CA l ~
[
g1annmanf MG Radiation Moniton'ng System gstem Software Requirements Spectrications p 12 2.3. User Characteristics a The computer system (maintenance computer and supervisor) checks any manual l Input for syntactic correctness and semantic plausibility; I . The user is able to check the basic system functions on line (Self-diagnosis reporting, voltage values, internal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal operation mode (Acquisition, alarm reporting...).
. The computer system reports its own defects and failures to the operator (possibly through the communication link).
2.4, General Constraints Refer to IEC-880, to the Software Quality Assurance Plan (4) and to the Verification and Validation Plan [5).
It has to be easy to connect any computer to the system by using the resident communication structure. The system must include facilities for redundant configuration (from the communication or from the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS. Only the on site maintenance computer will be able to modify channel's configuration.
The system has to implement standard communication interfaces as RS485 or RS232, as well known communication protocol as MODBUS/JBUS.
2.5. Assumptions and Dependencies Refer to the Software Development Plan.
=__ _ _ _ _ _ _ _ _
a T. ;%':"T.".L T 7,.".'J". M .";r,'""L*. 4" =.= ."l.:." *."J.. s_. 45179 cA
%.-, Radiation Moniton'ng System System Software Requirements Spectrications p 13
- 3. Specific Requirements 3.1. Functional requirements 3.1.1. Resident communication requirements 3.1.1.1. Introduction All the RMS devices have several digital communication links. The communication protocol ls MODBUS / JBUS and the transmission speed is by default 38400 bps.
The protocol has to be fully compatible with JBUS (as defined by EPRI) and with MODBUS (as defined by MODICON). This protocol, as used by MGP Instruments, is described in the RMS Protocol Technical Specification document (8).
MODBUS protocol allows communications between a master station and up to 247 slave stations, using point to-point or multidrop connections. There is only one station, the master, that is allowed to start an exchange. Each station must have a specific address l on the network (slave identifier).
This protocolincludes the following communication functions:
3,4 Read N words from the slave memory.
6 Wnte 1 word in the slave memory.
16 Write N words in the slave memory.
8 Communication diagnosis function (code 10 to 18).
11 Event counter reading.
It accepts the writing diffusion capability: Possibility to write the same data to all the slaves at one time by using the address 0 (no response).
The transmission speed is setup by softwere and must include the following speeds:
9600,19200,28800,38400,57600 and 115000.
Some limitations because of lack of processing power may be defined as :
. 57600 speed on maximum two communication links.
l . 11500u speed on maximum one communication link (for testing ournoses only).
The physical interface has to conform with the RS485 or RS232C norm.
$ C M *,%' L T ,*," A. T,. T O s %a.%%."l$4.' L*"2. e. - s-. 4S179 CA
l MkMP _
System Software Requirements Specifications
_ Radiation Monitoring System p 14 l
Inputs 3.1.1.2.
As an input, the unit (processing or display unit) receives a query from the communication link:
3.1.1.3. Processing This function has to:
- 1. Read the query message.
- 2. Ensure that the request is addressed to the unit.
- 3. Check the message integrity (CRC 16).
- 4. Check if the request is valid (good function number...).
- 5. Execute the action associated with the request.
- 6. Elaborate an answer. .
- 7. Send the answer.
The above functions have to be done within 20 me to minimize the response time.
To detect the end of frame, the unit measures the time between every character it receives: If there is a silence of more than 3 characters, it is considered that the message is ready. To accept communication using a modem with error correction and compression capabilities, end of frame time-out shall be set as a changeable parameter on second RS485 links, and on RS232 links.
Ma c second Rs485 l. Telephone bne with adapter link '
\'
" T t.PU : DU -
M ,
Mass computer M
Localcomputet if no answer has been received by the master after a user's defined time-out, the communication link is considered as free again for another request. This time-out has to
, be adjusted accordingly to the complexity of the network.
For broadcasted messages, the master has to wait 50 ms before sending another message.
D .l."l L 7 0 3 % 7 0 .*". O"'" T. ~ L~= . e 45179 CA
, f$ 2nmaummsEMGP _,
Radiation Monitoring System l System Softwarn Requirements Spectrications p 16 I
3.1.1.4. Outputs A response frame toward the master.
3.1.2. DU system functicn requirements 3.1.2.1. Introduction Three communication links are available on the DU. Two of them are slave and are connected to DAS computers, the Third one is a master which manages a small downstroam communication data link. The DU, in addition to its reporting function, has an important role in the communication management.
The DU can manage only 8 slaves on its master link, what ever type they are (DU or LPU)
Moreover, a local interface allows the operator to connect a portable computU (palmtop, laptop or local computer) for additional display and parameter setup. It is therefore possible to access the devices connected on the downstream communication by using this link, from 1 to 8 slaves Display Unit RS 485 link Q
,, ,l L (slave typ:) .~~. .a l
/~. A RS 485 link W % W ee~ t I~ W T DNS Comput ' .i;
_, (master type) b: l , y,h -
nev = Du> m
- p "W Y # *. -
??
RS 485 / ink (slave type) l
. 2 e
F' .
/ , .. a _ _. yg}? forredundancy : $i
,_, E S g 4- '
fg neu ~
f gp.y,pp 4 3
RS 232 link (slave type) Local Display unit f,,......_
s in SPU et DU) eampau ETE70~E.7,.7J.".70.%=O T E.7 5 7.1 % .. ,.s.,=. 45179 CA
$a).)MGP nemanun Radiation Monitonng System System Software Requirements Specircations p 16 3.1.2.2. Inputs Three dedicated slave links (two on RS485 bus, and one on RS232 fron: connector for local connection). These three links are reacting exactly the same way, and any of them can be used equally simultaneously.
3.1.2.3. ProcessinD When the unit boots, or when it receives an initialization command, it checks, by identifying slaves on downstream network, that the topology matches what it was configured for. If it does not find all the devices, it goes into fault mode, and an alarm is activated. (Operate relay goes off if setup this way).
Using the laptop wth MASS software, it is possible to setup this topblogy at the installation. A topology defines han many slaves the display unit has to manage, and for each slave, what kind of unit it is (LPU, LPU+SAS cr DU) and how to address it on the network (identifier).
The unit, by keeping in memory the topology, is therefore able to filter the data coming from the upstream communication and to re transmit this data to the downstream communication link in the following conditions:
. The message is addressed to a DU's slave unit declariid as a unit to manage externally.
. The data is not available in the DU memory (address out of main channel measurement area).
The DU keeps constantly in its memory a copy of the measurement and status data (basic data) of all the slaves (LPU or DU). This information is urdated periodically by the DU with a pollirg sequence (the frequency is configurable). The DU also updates an event memory that contains every fault that occurred in the DU or in the slaves (contact lost, alarms...).
If the DAS computer asks for the basic data area from a slave (LPU or DU) that is connected to the DU, the DU will simulate the response by sending the cata from its own memory (message with the slave address). This is to unioad the downstream communication link when the DAS computer updates its own status (poiling).
If the mastor accesses a slave unit through the DU (not for a basic raessage), the DU transfers the message immediately to the downstream communi .atior. link without any manipulation. The goal is to minimize the transfer delay through the DU. The DU cannot use the downstream communication link until the response from the slave has been received and re-transmitted to the master or until the response time-out is over.
M Z"#."" " O'L'*'J",.7.fa % C400.T.."IL"" sm 45179 CA
- _____.___.___m- . . _
u d assum m Radiation Monitoring System System Software Requirements Specifications p 17 If a LPU doesn't respond to a DU request, the DU will report the fault (alarm), and if the DAS computer tries to access this LPU, the DU will respond by sending an exception message (unit not ready). This is to avoid the DAS computer from spending too much time trying to communicate with a unit in a fault mode.
3.1.2.4. Outputs One RS485 master link.
3.1.3. LPU system function requirements 3.1.3.1. Introduction The LPU only reacts as a slave. It has two independent but similar links for redundancy connection.
RS 485 link
,.c (slave type) _ _.
- ._ . .. . v -
9 g-l M Local Processing 9
Unit (LPU) h g
O RS 485 link (slave type) scAoA computer e.w Gy c
,fj k
U I ) 5b .
v Display Unit g 3.1.3.2. Inputs Two slave links.
One detector.
Analog input (Optional) 3.1.3.3. Processing The LPU has different functions:
. Manage the detector and acquire measurements.
. Run a special algorithm to calculate an elaborated result.
. Memorize the historical trend and the event summary.
. Answer to the requests that are received from the two communication links.
l . Check its own software and hardware routinely.
Manage the analog input (if installed).
k'"#dM7J78./M%7O= O ~~n 5 7 0 71 1"L'Ou m ., 45179 CA s
gAannsnowsMGP Radiation Moniton'ng System System Software Requirements Spectrications p 18 l 3.1.3.4. Outputs l
The communication table accessible through the communication links.
3.1.4. Measurement output management 3.1.4.1. Introduction The main goal of this RMS system is to generate measurement outputs using data that is acquired from a detector and to display these measurements with their properties (as alarm status). The LPU is able to process up to 16 measurement outputs that are defined as channels using its own detector or other input devices like flow meter. The DU can display up to 4 channels for one LPU, the maintenance computer with MASS software as well as the DAS computer can display and manage the whole 16 channels.
3.1.4.2. Inputs
. Data acquired from the detector (s) (counting or current according to the detector type).
- Extemal data from the environment into the analog input. (stack or sampling flow l rates, temperature, nuclear power...)
3.1.4.3. Processing i
e For every channel (A to P), LPU processes associated algorithm with data from the detector, from the environment or from other channels as input.
. Write the algorithm result in channel activity area.
. Check alarm levels.
. Update channel historical trends.
M M 7,.",ZTiO7M "7 d 7,, 1~~~.7"."%.O . % 45179 CA
gulMGP menunes Radiation Moniton'ng System System Software F'equirements Speci6 cations p 19
/ ..
Detector Environment information (flow rate, y, _ , .,
temperature, nuclear power, Analog Acquisition and discrimination
[
I input...)
Mndow 1 Mndow 1 Mndow N y
Processing (Algorithm)
Processing Processing Processing (Algorr.hm)
(Algortthm)
(Algorithm)
/ fg e.
T e.
WW=
O
==
O
==
_v Tm e J To be displaydby DUs emumanu emrumsnu emumane em near.s ne
%. J v
To be displayed by extemal computer (such as SCADA or portable) 3.1.4.4. Outputs
. Parameter table measurement output area.
. Historicaltrend.
. Unit status.
2 M O *.*".LL70.*O*"E".7 d ~d 5 T.47.5T1.".,*" 4 1. e . 45179 CA 1
n k un Radiation Monitoring System System Gottware Requirements Specifications p 20 3.1.5. Operation modes 3.1.5.1. Introduction Every device (display or processing unit) that is switched on, sts ts in nortnal operation mode, but if a fault occurs or if the operator wants the device to run in a specific operation mode, the system goes to the specified mode.
3.1.5.2. Inputs The communication table.
3.1.5.3. Processing 3.1.6.3.1. Normal operation in normal operation, all the functionality of the system is available. The main task is constantly running and can be interrupted only by periodic treatments and by communication tasks.
The unit performs tests after each acquisition to check the integrity of the system.
There are two ways to exit the normal operation mode:
. By sending a command to go to maintenance mode.
. If the system detects a critical fault and decides to go in another mode (degraded or maintenance).
3.1.6.3.2. Maintenance mode The unit is in maintenance mode in the following cases:
. The operator comands the unit in maintenance mode using MASS or DAS computer.
. The unit detected a critical fault as hardware or software fault.
, its maintenance mode, the unit disables acquisition calculation and periodic tests, but maintains the kernel and the communication it means that the unit is still able to execute immediate commands .
This mode, because of periodic test disabling, can be used for critical parameter setup.
To retum the unit back to normal operation, there are three different ways:
4 e Send a command: Put the unit back in normal operation mode, e Send a command: Reset the Unit.
. Switch the unit off and on to initiate a hardware initialization.
U=7ETOTM7.70%1~n.7% TION. . % 45179 CA
Radiation Monitoring system System Software Requirements Specifications p 21 3.1.5.3.3. Degraded mode a
in the following case:
1
- e Critical parameters are not valid (integrity) -
1 The unit transfers the default parameters from the FLASH memory to the parameter 1
table, and goes in degraded mode. This is signaled in the unit status and reported in the
- event summary.
The critical parameters era checked periodically by the software.
- When a parameter is out of range the fault is signaled in the software status, t
To exit the degraded mode the operator needs to:
- 1. Go to maintenance mode.
- 2. Read the event summary to locate where the error is.
- 3. Correct the error by wrlung a new parameter, or by restoring parameters from i FLASH memory.
- 4. Go back to normal mode (see 3.1.4.3.2) 3.1.5.4. Outputs The communication table.
1 4
~
MM*a"M O2*O;TO.~m5,,m%:%7sm a.mw_, 45179 CA s
-,--m----------v. .. -- .-e-,m,-,., ewe....,--y,--- .----,s--.=.,,-w,.., . , -, , , - - - - --,,wm. x - ,, .,,.. .--.m.ev.,-mw-.-,-s,--.,w,,c..-r, i..,.. %-
l gd ansaumussMGP Radiation Monttoring Syt fem System Softet hquirements Specerications p 22 3.1.6. Monitor w!th multiple detectors 3.1.6.1. Introduction By using different detectors associated with several LPU, it is possible to group measurement outputs on a display unit in such a way that only the most important activity is displayed on the screen, or is reported on the analog output. There are two main applications that use this mechanism:
e Group of area monitors that are distributed accross a room: In thb case, only the highest level has to be displayed and reported.
. Multi range monitors: The display unit displays only valid measurements (from the detector that matches the right range), and is able to manage range switching (as pump start for sampling monitors).
3.1.6.2. Inputs Detectors.
3.1.6.3. Processing On the display unit, there is special screen nr ued Maximum screen, which displays the maximum activity of valid measurements from the DU's slaves.
On the LPU, it is possible to setup a low and high range activity for the first channel (A).
If the activity goes out of this range, ne measurement is considered as invalid, and a flag in the processing status allows the DU to recognize if the monitor has to switch to higher range, or to lower range. If several activities are valid at the same time, the screen displays the highest one. The same process app!!ss on the analog output if maximum activity is selected as input.
,+. ~ ~ ., .a m ..~ ,. a Detector 1 LPU 1 Display Unit N <= 8 e, -
"9 Maximum Semen Detector N - LPU N p
3.1.6.4. Outputs Display unit screen, and analog output.
M ."" M ,. L 7.o.7m*J ",.70." "'J"* OT.575 C"*n"i"" o . . S.m. 45179 CA
v t, -
P%MRP anmanuts System Saftware Requirements Specirications has tion Monitoring System p 23 3.1.7. Comr /:ad management 3.1.7.1. Introduction This is a mechanism to send commands to the device through the regular communication functions (read or write words in the communication table). RMS devices do not use MODBUS specific command functions because of the modularity the system must have. Indeed, it is possible to add a communication extension board to address the parameter table directly without using the intemal protocol; the command process has to i work in a transparent mode.
3.1.7.2. Inputs The communication table (command area).
s 3.1.7.3. Processing
\
3.1.7.3.1. Command management Note: Evm when command process is common to the system, command codes and functicns are specific to each unit.
The command svorriit enrnposed of two bytes:
Command state / parameter
- 16 8 0 To start a command, set the Command byte to 1, the paramcder is written in the other byte. In case of a digital output, the parameter is 1 to set the output, and 0 to reset the output.
As soon as the unit acknowledges the command, it sets the command byte to 2
. signaling that the command is running. When the command has been completely executed, the unit resets the command byte and puts the command result in the state byte.
The result can be:
. Between 0 and 127 if the command executes successfully. This value reflects the output / command state (it should usually match the parameter value).
. Between 128 a.4 255 if an error occurred.
L DJ'%67'f,5%%7d747570ZO.a.e. 45179 CA
go annunnesMGP Radiation Monitoring System System Softwarc Requirements Specifications p 24 Examoles:
RehQot the system:
. Write Ox0100 at the Reset unit command address.
- In this case, the execution is immediate: The unit resets the command word and does a warm reboot.
Advance the filter:
. Write Ox0100 at the advance filter command address.
. At the end of the current acquisition, the unit acknowledges the command by setting this word to Ox0200 and commands the filter advance motor.
. If everything goes well, this word is reset to Ox0000, otherwise it is set to 0x00FF to signal that an error occured. .
Transfer the downloading buffer in nage 12 of the FLASH memorv:
. Start transfer by writing Ox010C at the Transfer program buffer command address (0x0C is the part. meter).
. The unit acknowledges by setting this word to Ox020C, and starts ;he transfer.
. When transfer is over and if no error occured, this word is set back to 0x000C by the unit.
Wd L"*".*'" ".u.%: TO m~w L~a ~ MTsm. a. - s.~. 45179 CA
1p' },MGP anmanens Radiation Monitoring System ~
System Software Requirements Speed: cations p 25 Following is a flow diagram which illustrate the start of a command from a master computer.
Wrne the command word in the destination unn
+
..Wat time to allow the unn
-> to execute the command (50 ms)
+
Read back the command Yet word is the command running ?
Command Time-out Check the command resut No error Error I
k 9 &
3.1.7.3.2. Digitalinput command association The system includes a mechanism to start commands on remote detectors (LPU) using l digital input of a display unit. Ihts. allows the system to manage up to four switches wired to four different display unit digital inputs.
The display unit has to be configured to broadcast its digital inputs to its slaves. Then, up to four commands can be associated with the first four virtual digital inputs. These virtual inputs have to be parametrized to reflect the display unit input state where the i
switches are connected. By latching these virtual inputs, the LPU is able to detect any change, and to run the associated command:
- Input goes from OFF (0) to ON(1): Run the command with 1 as parameter (enable).
. Input goes from ON (1) to OFF(0): Run the command with 0 as parameter (disable).
Example: Bypass switch to disable alarm reporting.
l w Because broadcasting is done periodically, if slaves miss the first change they will detect it anyway during the next broadcasting exchange.
M E T b ~ = =*. % 7. 7 0 ~ M .'J ".U Z " O . . e . 45179 CA ~
gnl!an'auamnsMGP Radiation Monitoring System System Goftware Requirements Specifications p 26 3.1.7.3.3. Output emulation mode By running the output emulation command , you can simulate different system states, it is possible to generate up to 20 test steps that will run after each acquisition.
This mode is disabled automatically when all of the 20 steps have been executed, ilt 1
Obtain acquisition information from detector ib 2
Process Acquisitioninfometion using spedfied algortthm ir 3
store measurements in historicaltrend memory 4
la Output Emulation Mode enabled? No*
Ys 5
Change the unit status according to output emulation command 6
s the command at No+
number greater than 207 Ys W
7 Disable Output Emutation mode i f .w.
Perform Proces. . g on tne measurements and update the y
unit status (alarms, etc.)
t
- 17. *J".""M **" eta",L*~d~" ""' *'~;="0;""".'"l1.
- - 45179 CA
gd annunnssMGP Radiation Monitoring Systom System Software Requirements Specifications p 27 l The sequence is defined in the output emulation parameter area. Each step contains the command code, the channel number (between 1 and 16) and a parameter (a virtual measurement for example).
commer paramener l commer l l l 64 44 32 0 Here are the different commands:
. No operation
. Virtual acquisition / processing fault
. Virtual unit status fault
. Virtual software fault
. Set activity measurement in the specified channel to a virtual value.
. Set integrated activity measurement in the specified channel to a virtual value.
. Set specified channel of the unit in alart. Measurement is set to the alert threshold value.
Set specified channel of the unit in high alarm level. Measurement is set to the high threshold value.
. Set specified channel of the unit in high/high alarm level. Measurement is set to the high/high threshold value,
. Disable output emulation.
By using the MASS software it is possible to define the sequence for each LPU. Once this sequence is entered and memorized inside the unit, there is just one command to send (from the MASS or from the DAS computer) to run the sequence.
Sequence example to check DU alarm lights, and DAS alarm reporting:
1 Set unit alarm level to alert lThe yellow light should turn on j 2 Set unit alarm level to high lThe red light should turn on l 3 Set unit status in fault lThe green, yellow and red lights shouldl l turn off l 4 Disable output emulation End of sequence; go back to normal operation mode ML""LTm*f" '""' ",,7d _ m*"* * ** *"*' ""O L""",. % 45179 CA
3nIannannensMGP Radiation Monitoring System System Software Requirements Specifications .
p 28 l 3.1.7.3.4. Program downloading process in downloading mode, the unit disables any processing that was done in the regular program memory zone. The kemel that runs in a critical part of the memory stays enabled as well as the communication task, and the command tasks.
The downloading process from a master computer shall be:
I BEGIN m i v
ir Place the unit in maintenance mode ir Clear the program memory 3r Start at page 0
=
c 1r Transfer the program part (4 Kb)in the downloading buffer area 1 F Transfer the program buffer into the FLASH memory 3r-Write error ? Yes %
N,o Next page ir is it the last page ? Yes+ Reset the unit ir END ET70*.ME7M ".70.~ane O*Ew" E7.m. a. no. s.n,.o 45179 CA j
y g MGP ggnmang -
System Software Requirements Spedfications --
Radiation Monitoring System p 29 3.1.7.4._ Outputs The communication table.-
3.1.8. Input / Output management 3.1.8.1. Introduction -
In RMS architecture, each device has its own function, but it is possible to group them to build complex monitors like SAPlG_ or PING. Those monitors use the LPU as an intelligent detector, and LDU as electrical command and measurement reportir.g.
Because the LPU provides a ready to use result, it needs to get information from the whole monitor (digital or analog input, monitor state...). As a master on the network, it is the LDU's role to gather this information and to diffuse it to its slaves (LPU). Moreover, the LDU has to control and command the monitor process automaticaly.
To implement this, the DU has to:
. Determine the monitor state using its digital and analog inputs, and possibly using detector (LPU)information.
. - Command its digital outputs accordingly to the monitor state.
. Diffuse this state to its slaves.
. Report this information intemally.
Tlie LPU has to:
. Process detector state and measurement result using its acquisition information and data given by the LDU.
. Give the master access to this information.
. - Report this state intemally (digital and analog outputs).
3.1.8.2.- inputs
. Digital and analog inputs if available in the DU.
. Communication table.
L"S"."b" *'*M;7.#,0.7.," "" """J* .,".~O ~n ~n . m. s- 45179 CA
$' bantauutansMGP Radiation Monitoring System System Software Requirisments Specifications p 30 3.1.8.3. Processing 3.1.8.3.1. Output management Each device has several outputs:
. A DU has 5 relay outputs to command external alarms, up to 16 outputs to command extemal components (pumps, valves...) and 3 relay outp'uts to command check sources.
. A LPU has 2 or 3 relay outputs (depending on the option) to report externally the unit state (faults or alarms).
To command report relays, the unit uses its intemal status as alarm levels, proccasing modes, faults. ,
On the DU there are 16 possible power outputs to manage. ILis possible to use an l automation process that is included in the DU software to command them automati%ily.
By using commands, or a screen on the DU, it has to be possible to force the output manually in a certain state (on or off ), or to put them back in automatic mode.
To be able to manage a screen that will display the output state, and that will change them through the network, a special mechanism has to be implanted even when the DU is not directly wired to the skid.
,, . . . . . . Nmmand,to,@,ange outputs
, __ RD -Ca5[nSt" sf . - , _ . . - . . . . ,
LFU Data Link '
,p PUMP E
[ '5 -
~
~ VALVE 1 E v-l I '
l -.....- _._ 2 LDU-Skid
\,
VALVE 2 E 41 5
- l Data Link VALVE 3 V1 l - '
l PUMP l Current output state
~> .-
iV3 DE"ETh~m" Z "i.UO 7M.U.U ZOO. . ,m s=<.. 45179 CA
g,llMGPannunuts Radiation Monitoring System System Software Requirements Specifications p 31 3.1.8.3.2. Automatic output command mode on DU To control and command external components, the DU processes logical operations betweer, internal binary variables like digital inputs, output states, intemal flags, timer information or processing status.
There is also a sequencer that allows sequential opemtions. This sequencer allows up to 16 different states, and 16 transitions. To define the automation, the operator has to enter the transition equations to go from one state to another.
it is possible to use up to six binary variables with any kind of binary operation to find out in which state the output has to be. We define for each output & Boolean algebra equation.
Output = F(input 1, input 2, input 3, input 4, input 5, input 6) ,
These are variables usable in these command logical equations:
Variables to command using equations:
. Sixteen local digital outputs
. Sixteen intemal flags reflecting an internal state (these flags can be diffused through the DU data link)
These are the intemal states that can be controlled using intemal variables (without equation).
Variables to command using others variables:
. Sixteen sequencer transitions
. Five timers with programmable duration (from 10 ms to 650 seconds); timers are loaded (initialized) on command, and are decremented automaticaty every 10 ms; it is possible to use later the time-out information as an input.
This is the way to program logical equation in parameter table (with six 16 bit words):
First operator input 1 Second logical operator input 2 Third logical operator input 3 Fourth logical operator input 4 Fifth logical operator input 5 Sixth logical operator input 6 4 bits 12 bits 1 % C "* E"T Z E 7 0 7 M .n TuOO7.m. no.s . 45179 CA
gMGP annanen Radiation Monitoring System System Software Requirements Specirications p 32 Operators can be decomposed as follow:
operatkvs code Negatkwt 3 b4 1 bn Operation Code Operation l Conment
. 0 END (No operation' This operation indicates the end of the equation. The automaton considers the treatment as over and will not Jse newt inputs.
1 BEGIN (straight) ~ This is to use for the first variable (there is no previous result, therefore no operation, but we use the input state as a starting point) 2 OR Logical OR between previous result and vanable
- 3 AND ble 4 XOR Logicalexclusive Logical AND between OR betweenprevious prewresult e arQ. '.esult and variable 5 Unused 6 Unused 7 Unused Negation Code Operation Comment 0 Straight Use the vanable state as an input 1 Negation Uses the complemented variable state as an input Output is calculated using inputs and operators from beginning to end. Therefore,
~
parenthesis are implied from left to right. If, for example, we want to program the following equation: output - (Input 1 OR Input 2) AND Input 3 the AND operation hac to be done at the end. Here is how the equation should be:
BEGIN input 1 OR input 2 AND input 3 suo lt means: output . (((Input 1) OR Input 2) AND Inpuc3) ine - - , - e, m ., % .t - . ese.co n u ou, en - g 3,7 9 3
% Wadutte et reorcibCtm totale eu partiste Os Ce documert sort rigoureusemert reertMet. ed autorisarm ecree de rios Services r
1 l
$h alInstauwwrsEMGP Radiation Monitoring System System Software Requirements Specifications p 33 Binaryinputs to command output:
. Sixteen digital inputs (from local interface or from remote DUs through diffusion process)
. Sixteen commanded intemal flags.
. Sixteen flags from local or slave's operating status
. Sixteen flags from local specific or slave's acquisition status
. Twelve flags reflecting local digital output states
. Four timer time-out information (set to 1 vihen the specified timer reaches 0)
. One analog input out of range flag (set to 1 when the specified analog inpet values gets out of range specified by two thresholds) ,
. Sixteen sequencer step states We can use digital inputs to get data from external components. This is used to know the moni'or status as pump fault, pressure fault...
By using slave operating status bits, it is postible to get commands from a LPU like advance filter, isolate monitor, switch to accident range, and DUs own operating status can be used to take care of specific modes like unit in maintenance mode, unit booting, unit in alarm...
Slave acquisition status informs the DU about acquisition faults like Filter fault, Total activity too high...
The DU output status can be used to inform a LPU slave about the monitor status like Pump ON. It is also possible to use this output information when controlling another output.
The timer " time out" flag can be used to associate duration in the control. It is possible to parameter in which condition the timer goes in time-out (command mode and duration).
The analog input out of range flag can be used to command extemal devices according to an analog value. For example, start sampling if nuclect power gets lower than a specific value.
3.1.8.3.3.. Exported digital input and intemal flags it is possible for a unit in the downstream communication to use input information from any DU that is connected on the same communication network.
The DU master according to the configuration gets the input data from itself or from a DU slave, and diduses it to all the slaves by using a diffusion process (write data to the address 0 in MODBUS standard).
Two channels are available to permit the data to come from two different units. Each channel can handle 16 bit information. If a DU wants to diffuse its data, it just has to define in which channel it wants to put the data in.
b" L~ C" 0,*.%u"707O%OE%. .som. 45179 CA I
ossimausts Radiation Monitoring System System Software Requirements Specifications p 34 Four word locations in the parameter table are reserved for this diffusion:
1 16 Intemal flags from first channel 2 16 Intemal flags from second channel 3 16 digitalinputs from first channel 4 16 digital inputs from second channel The LPU can use the information it receives periodically by defining virtual flags. A virtual flag is setup by defining the channel number (1 or 2), and the input number (among 0 and 15). Up to 4 virtual inputs and 8 virtual flags can be defined on a LPU.
Virtual inputs can be used to give information to the LPU (as filter advance command),
and virtual states are reported directly into the acquisition status to give the LPU the 7 status of the complete monitor, c channel (t or2) attlocaten (015) l 16 12 8 4 0 if this word is set to zero, it means that the virtual information is unused (no processing done'on it).
3.1.8.3.4. Exported analog input management The analog inputs from the DU can be diffused on the same principle as the digitalinput.
Two channels are available, but there is only one 16 bit integer value per channel.
Therefore we don't need to select which input to use.
The virtual analog input is only defined by the channel number.
e o channel (1 or 2) 0 16 12 8 4 0 3.1.8.3.5. Exported measurement management Measurement results from LPUs can be broadcasted on the same principle as the digital input.Two channels are aviable. For each channel, the DU broadcasts the status, the measurement result and the measurement unit.
t 3.1.8.3.6. PING parameter setup example This is a particulate, lodine and Noble Gas continuous air monitor consisting of sampling equipment, three LPUs subassemblies and a LDU to control electrical sample line. We generally add to this configuration 3 RDU to display data from the 3 measurement channels, b " m "oon." b' ~ i O W E *i. U d O W E ~n 7 0 L * " E . s 45179 CA
gl?) N\annummsMGP Radiation Monitoring System System Software Reavirements Specifications p 35 Hafngr}Lconfiguration Monitor Cabinet
< ,,_ _ L. ; ~' ~
' Data highway to ,. , ,_
LPU int a RDU LII Data highway Particulate y &forROU access Particulate ,
s . . - ,v,3 l s. . ~. w and for l e for a ces j case of a s .., n . 2 2
'/ p. malfunction l l . . .;,. n a ,
LPU Gas L1 " Master G'
}
ROU Gas P' s - s ~ ~- . .:~A :
l Data highway toinfonn the centrali l computerabout the complete monitorstate J
{ '
@ ** l.
Fj ! Central computer
. - . . ) - --
We have to setup the master link of the RDU in such a way that it gets data from the 3 l LP_Us_and diffuses this information to its RDU slaves.
The DAS computer accesses to the LPUs through the LDU, but if something goes wrong on the LDU data highway, it is still possible to access to the LPU through the RDU gas sub network, if the two networks are separated, there is no way that.a collision on the network can appear if the computer tries to access to a LPU by using the redundant data highway. If these two networks are connected together, the computer must first disable the LDU sub network access, and then authorize the RDU sub network access.
The monitor status is composed of information froii1 each LPU and from the LDU thbt controls electrical components.
3.1.8.4. Outputs Communication table.
M L7f7 O L7.0%L,0!501"~ O % 70707.m..,s- 45179 CA
11 iMGP N\natnumun Radiation Moniton'ng System System Software Requirements Specifications -
p 36 3.2. ExternalInterfaces [
L 3.2.1. User Interfaces 3.2.1.1. LPU user interfaces The LPU has no user interface. This is a black box with no display and keyboard. The user interface is deported to the DU, DAS and portable computer (MASS).
3.2.1.2. DU user interfaces 3.2.1.2.1. Local display unit interface Status lights Buzzer
~~' m u, p' - t-tp.~y;3:gs:y;gn eev m,9- ~- . .
~ _,M-w, q.y n ;, _,
Vacuum 51' Y .s .,xt:nW'~ Fluorescent
- .. w ~= - 9
- &Rc Rid ;c Display 2.:."*.... OW . ~ 91'Q - '
tt';%"' 9Ju,,,Ki-L%4' . Status and gM?nWyc alarm LED w
g.'m.',w[2.
. .Y'i' Key w e-,
" , ' ,. h, f.'. . , , l. Keyboard
,s. m n: y m w .
W$4NC t
~-'
~ _ l.
.- Ld:,y* f~ Portable
?
leg,,]a t;~ ~' .= Maintenance
- ~. ; .: . -Computer h
3 y;j,' ' :.l connection lLE.5,s m a m;m a e,m m,p The status lights and the unit status display show worse case condition from a connected LPU.
The DU shows data from the unit selected through the keyboard, or to the last unit that went in alarm.
i= - .n ron. - m e.,.r m . m .. .m ,n- .no. iouieu,..en nsa Putmcalm traducten et recrt> beam totale eu pm*eue ce ce cbcumert sors normseusemerv assertMes, sad autarsaten 4crte ce nos Serwcas ggda
gbannunaisMGP Radiation Monitoring System System Software Requirements Specircations p 37 l
The keyboard can be used to change the screen display. The SELECT button is used to select the information you want to look at, or to acknowledge the alarm. The arrows are used to change the channel displayed.
3.2.1.2.2. Remote display unit interface The remote display unit has the same interface than the LDU exept that the lights are reported as relay outputs.
3.2.2. Hardware Interfaces 3.2.2.1. MODBUS/JBUS serial link The resident communication links (slave or master) are serial type interfaces with RS 485 multi-drop physicalinterface.
l It is possible to select the baud rate by software from 9600 to115000. On the LPU, the two slave links are independent, and the baud rate can be different for each of them. On the DU, the four links are also independent with a specific baud rate for each of them.
To detect the end of frame, we have to use a hardware time-out counter that is independent to each link. The resolution has to be around 200 s and the maximum duration around 50 ms (an 8 bit timer fits the requirements).
The serial interface has to be able to send interruptions to the micro-processor in the following cases:
. A character has been received.
- The character transmission is over.
- End of frame time-out.
M%%%T==M7.70747. COO 7 ,=smo. 45179 CA
gdi annuanensMGP Radiation Monitoring System System Software Requirements Specifications p 38 3.2.2.2. Program memory The program memory is decomposed in threc parts:
7 Part descriptions Functions Usedin Memory Particularities type Base program Communication Maintenance mode EPROM Cannot be altered Commands Normal operation mode
] Degraded mode
{ Application Acquisition Normal operation mode FLASH Can be
'L - program Algorithm Degraded mode downloaded inputs / Outputs Commands
.g I Default R/W Selfchecks Degraded mode FLASH Can be t parameters programmed by command 3.2.2.3. Data memory The data memory has to be a battery saved, static, random access memory (RAM). It contains the parameter table, the program data memory and variables, and the microprocessor stack.
. The stack size can be estimated at 4 KBytes.
. The variable and program area need about 16 KBytes. ,
- The parameter table varies according to the type of the device.
Device Last Parameter table l RAM size parameter size address DU 11340 22 KBytes 128 KBytes 16 Channel 15499 30 KBytes 128 KBytes LPU LPU-SAS 17999 35 KBytes From 128 KB
+ Spectrums + Spectrums to 512 KB The LPU-SAS configuration depends on how many spectrums we want the device to memorize.
l1 *,J C L* O C . M E 7 d l~ O~".17ME*""1. ,- s 45179 CA
galMGP anmanuts Radiation Monitoring System System Software Requirements Specifications p 39 3.2.2.4. Hardware watchdog A hardware watchdog has to detect any system malfunction. The software resets l
periodically the watchdog. If the microprocessor locks up or if there is a software problem, the hardware watchdog has to reset the entire unit. It may also signal the defaul; by activating an alarm relay.
See 3.5.1.1.3. for more details about watchdog control.
3.2.2.5. Power supply monitoring The system has to be informed of all power supply faults since they have to be reported in the event summary table. When the voltage reaches a certain low level, the microprocessor must receive an interruption, and must have enough time to perform interruption process (around 100 ps). .
We don't have to save data memory because of t<4w backup.
Each unit also controls its power supply voltage by reading the value from an analog to digital converter. If voltage level is abnormal (user's define thresholds), the unit signals the fault.
3.2.3. Software Interfaces Any type of software can access the system since it integrates a MODBUS protocol interface. It is then possible to connect specific softwares that can manage extended capabilities as:
. Additional display functions (on color screens with graphic display).
. Process management.
. Test, calibration and maintenance functions.
3.2.4. Communication hardware interfaces The resident communication interface meets the RS-485 standard.
b~U.LTM"70.~O~,n O.L~ . . - % 45179 CA 1
Pa hAmmauanutsMGP ~
Radiation Monitoring System System Software Requirements Specifications p 40 The RS-485 standard accommodates the requirements on a balanced transmission line used in party-line circuit configuration. It permits multipoint applications where multiple
! drivers and receivers share the same line in data transmission.
The transmission line which is intended to be 120 Q twisted pair is terminated at both l ends. The drivers and receivers can be distributed between the termination resistors.
1000 meters maximum 4 :
Terminator Pull-up on one station only g g ,., bus on a twisted pair a // i!
c
$% N A A, A, Teb. nator 2"
, XX XX V V XX V Transceiver Transce6/ er Transceiver The communication will operate properly in the presence of reasonable ground drops, withstand line contention situations and carry 32 drivers and receivers on the line.
3.3. Performance Requirements 3.3.1. Downstream communications link loading The following performances are based on a standard speed of 38400 bauds. To get correct response time, the DU shall be able to scan up to 2 slaves, and simultaneously to update 1 slave DU per second.
We assume that the slave responds within 30 ms after receiving the request, and that the master waits 50ms before sending another message.
We can define a critical (minimum) polling time according to the configuration :
Cri ticalPollingTime= (NbSlaves +NbDUSlave s
- 2 ) /4 enYemNe~n .i Esoupe Nt7 sera
- ~
woYnsaur S .a.noss me , 45179 CA
_a
ipbMGP annuanuts Radiation Monitonng System System Software Requirements Specirications p 41 3.3.1.1. Maximum configuration We meet the maximum configuration by connecting 8 slaves to the master RDU. To increase communication link load, we manage 4 DUs slaves in which we have to transfer the data from the 4 LPUs.
/n . . .a ss . . . .-.a LPU1 - Master RDU
/r c ~ "'
P P -
m *'
CentralcIo puter LPU 2 B__
p s.. , n .a m - .'
RDU 11 E LPU 3 P
/ n- .n.~a
~
RDU 12 LPU y4 b
..~~-2
- s. , . .m- - - - -
ROU 14 LDU 10 1- The DU scans the B slaves:
2- The DU updates the 4 DU slaves intemal status about the 4 LPUs.
In this example, we get 4 seconds as the minimum polling time.
3.3.1.2. PING configuration In the PING configuration, we have 3 LPU slaves, but only one DU to manage them.
Mcreover three RDU display information from each LPU.
/.. - n n sn -~~n as LPU Gas gg sawwm / ,mn. . . a :
LPU g RDU i lodine y lodine .
/ wmmm s -~ wa .
LPU RDU Particulate Particulate
/_.. . . - a Master LDU P l'" f2il 'l Central computer Master RDU polling time must be set to 3 s. and master LDU polling time to 1 s.
M b 7 M i. L" E 7.d O. ~= O ~ M O C L ~ sm , 45179 CA
$l, aanumensEMGP Radiation Monitoring System System Software Requirements Specifications p 42 3.3.2. CPU performance The system software includes a function that computes the actual CPU load. The result of this function is accessible through the communication table, and is updated after each acquisition cycle. This is the CPU load as a percentage of maximum capacity. To perform this function, the CPU measures the duration it spends waiting the next acquisition (this is done after the last acquisition process).
The total CPU load shall not exceed 60%, else a status fault is declared.
3.3.3. Memory The Random Access Memory contains static data (communication table, global variables...), and dynamic data (stack, local variables...). The dynamic data, memory utilization, as a percentage of available capacity shall not exceed 60%. To verify that, we will by using a debugger
'/ 1. Fill the dynamic memory with predefined values (like Ox5555).
J'
- 2. Leave the system running for a week.
- 3. Check that no more than 60% of the allocated memory has been altered.
3.4. Design Constraints 3.4.1. Standards compliance It is not recommended to use a real time operating system kernel. The system has to integrate only one task that is executed cyclically.
According to the system complexity, we will use interrupt driven program structures for the following functions:
. Communication management.
. Real time clock.
. Power fault, or watchdog non maskable interrupts to be able to memorize the event.
. In some cases, interrupts will be used to monitor the acquisition board, if precise synchronisation is required.
3.4.2. Hardware Limitations The CPU the' 's used is a Motorola 68000 at 12 MHz. There is no space to add a mathematict ^oprocessor. We use a backplane bus to communicate with external boards (stancard G96-16 bit bus Gespac compatible).
M.C."M CO " 7.f,0.="",""O" T. O C*"L" no. s 45179 CA
4 g MGP nanuanuss Radia* ion Moni:on'ng System I System Software Requirements Speci%tions p 43 3.5. Attributes 3.5.1. Security 3.5.1.1. Fault detection Errors in the software are difficult to detect; nevertheless their presence can be uricovered by placing checks at various levels in the software structure. Some arithmetic errors can be minimized or effectively eliminated by careful arrangement of the arithmetic.
3.5.1.1.1. Machine instruction level As part of the boot test, and when the program is downloading in the memory, the first thing the unit has to do is ensure that the loading operation has been carried out correctly. For this, a simple checksum (CRC 16) technique will suffice. The checksum is positioned at a known location within the code element. During the test procedure, the process can calculate a checksum of the code element. This value is compared with the checksum embedded in the code. A discrepancy causes a fault to be signaled (software status). In this case, the unit goes in maintenance mode to preserve the CPU from running the code.
Volatile memories (RAM) are checked cyclically during the CPU waiting period. This is to detect any hardware fault that can occur, by writing and reading the memory content.
This function doesn't alter the data that is stored in this memory. it disables the interrupts to avoid any undesirable access.
3.5.1.1.2. Code module level Checks have to be included in an attempt to guarantee the correct operation of code modules within the processes.
Assertions Fault checks have to be inserted explicitly to form part of the code itself. The programmer embeds logical assertions in the code. These take the form of statements conceming the expected behavior of the module at different points in its execution.
Should an assertion prove false at run time, a fault is flagged (software status) and recovery action taken. The introduction of assertions automatically introduces additional, redundant code into the software.
ME"".LTio 'M7.7C7MOCL'"O. .sm.. 45179 CA
l
$Yuhns,numenn%MGP ,
Radiation Monitoring System System Software Requirements Spedfications p 44 -
1 Assertions take a number of different forms.
Range checks ensure that the values of data variables lie within a specified range during execution. They have to be placed for all of the following cases:
- 1. Logarithm calculations
- 2. Square root calculations
- 3. Array access (range)
State checks verify that certain conditions hold among the program variables.
Reasonableness checks analyse data input to or output f om a module in an attempt to discover impossible or unlikely values. Here are the variables to check:
- 1. Unit address on the network
- 2. Transmission speed ,
Y
- 3. Counts from the detector
- 4. Algorithm parameters
- 5. All the analog inputs $
Assertions mechanisms ve of most value during the construction and testing phase. 4' The existence of assertion mechanisms, however, implies extra code, whictL can l produce an unacceptable overhead in a running system. Therefore, the provision of assertion code can be made optional at the compilation stage, ideally, as many assertions as possible should be left in the code.
3.5.1.1.3. Audit level Whole modules have to be introduced into the system with the sole purpose of error detection. These ' audit' modules check the hardware status for invalid status or conditions. They flag an error if they detect any discrepancies, watchdoag The hardware watchog has to be reset by the software. To be sure that the software is running correctly, we get the watchdog input in the real time driver module, and we check if the hardware watchdog is running correctly. This module gives this information to the main task through the shared memory.
The main task (application program) checks this flag at every acquisition cycle, and resets the watchdog if necessary.
D L 7,.Z O U."27.7 E O" C"OOU Z%. . rm s--. 45179 CA
gdiaannanansMGP Radiation Monitoring System
, System Software Requirements Specificatens p 45 if one of these modules does not work, the system signals the fault:
htodule Fault detected by How Action if fault Hardware watchdog Real time module Measure the watchdog clock Setup the unit status duration word Real time module Hardware watchdog The module did not inform the main Reset the unit task about the watchdog initialization.
Main task Hardware watchdog The module did not initialize the Reset the unit watchon in time Acquisition module Main task (minimal The application does not get Setup the unit status counting) enough counts, or intemal test (as word electrical test) that is done
~
periodically falls.
Communication DU/DAS There is no communication (no Fault signalisation response)
RedundantInformation '
The system will include delibeiate redundant information. The audit process will flag an error (software status) if it finds two versions of a critical parameter to be inconsistent.
For increased reliability, the redundant parameter will use a different code (2's complement),
The first 400 words in the system parameters (address 0 to 399) will be considered as critical parameters and will be reproduced at the address 400 to 799.
All parameters that are critical to the system operation will have to be defined in this aIna, Definition of critical parameter is done in appendix A.
Communication link watchdog l Because communication is using hardware interruptions, the system has to venfv.that links will still work if it misses an interrupt, Especially when the unit sends a frame, it puts the line in transmitter mode, and waits for the last character to be send before putting back the line in receiver mode. To prevent the unit to stay indefinitely in transmitter mode in case of a line malfunction, a software watchdog resets the line in receiver mode ifit detects any locked state, 3.5.1.1.4. System level
- n order to implement fault detection at the highest level, it is necessary to observe the system from an extemal viewpoint. This perspective is provided by additional system hardware.
The system must include hardware to observe electrical activity on outgoing lines:
Relay output The output has to be connected to an independant input. The system must check this input after each output command taking care of stabilization duration (about 10 ms).
Power supply: The voltage level is checked. If the value is out of range, the default is signaled in the unit status.
Detector input if the number of counts is below or above a reasonable level, a fault is detected.
Ol" ";1"""0=.0",%ll".01%*"";""2.**:~.J' "0;"L":O. s_ 45179 cA
pd whaswawmsMGP Radiation Afonitoring System I System Software Requirements Specifications p 46 APPENDIX-A Standard parameter table From To Area description DU specthe Area description Specinc Writting access LPU or General to 0 49 General system parameters System
_ Critical 50 99 Specife system parameters LPU/DU 100 129 Channel measurement configuraten l Topology definiten LPU/DU Access in 130 159 input / Output parameters LPU/DU maintenance 160 295 .< .N - Automatr,n DU Access in 296 399 Virtual status definition Intemal flag definaten LPU/DU maintenance 400 799 Integrey checking ares (entcal parameters) System mode only 800 1439 Channet defirution and parameters Stave data copy Unit Regular 1440 1499 Common algorithm parameters : Unit 1500 1249 Acquisition parameters Unit Operationnal
,,{,
1550 1599 Treatment parameters '
.Ei Unit parameters 1600 1649 General status control parameters System any mode 1650 1699 Spectre status contni parameterr ln m Unit Access in 1700 1799 Report parameters LPU/DU 1800 1876 Output emulation parameters S' ave parameters LPU/DU 1900 1999 -
"amw -
2000 2127 Measurement bosal charactenzation LPU/DU (EEPROM) 2128 2499 w a c-W ch . .~ Unit 2500 2549 intemal diffusen area System 2550 2599 Extemal diffusion area lR ~ v.i % !/u LPU 2600 2699 User's information LPU/DU 2700 2799 nwunc - - " LPU Acquisition fault desenption LPU/DU
,2800 2829 Acouisition related command area input /outpqt command ares LPU/DU 2830 2839 Immediate command area System To be 2840 2859 Maintenance command area System changed 2860 2863 Command parameter area System frequently 2P$4 2951 ' ' iu es4% w -
W ?" - "- '
2952 4999 Program downloading buffer System 5000 5019 Unit state information LPU/DU
$020 5039 Dynamic hardware information System data 5040 5079 Munstor acquisition information lm ' e *- -e Unit 5080 5099 Processing information System 5100 5133 Main enannet measurement results Unit status LPU 5134 5209 Extended channel measurement results LPU
$210 5249 " c: 't.we." . ;e' q
$250 p ,' m. LPU 5432 Average measurements '~
LPU Read only 5500 6896 Event summary System 6900 15179 Histoncat trend LPU/DU 15400 15499 wnuw - -
~
"w Unit 15500 17562 Spectrum transfer area Unit Specrfic to LPU/DU means that one area is related to the LPU unit, and the other to the DU.
Specific to Unit means that the parameters are specific to each kind of LPU or DU unit.
Specific to LPU means that the t rea is specific to the LPU (unused by the DU).
Specific to DU means that the area is specific to the DU (unused by the LPU).
Specific to the System means that parameters are common to aD the units (DU or LPU).
s The punscate vanswoon or .,.am egner partly or wticey, at the cocumens a not anowea wanout ow wniten consent halcatm Irsducie et reprochsetson intale ou partees de ce document sont ngoureusemert ever@tes, sauf adensation 4 cree de nos services 45U9 G i
. . . . . . . _________i
q g--
b (Ftw IDCNs Orfy)
CONTROL ROCN ORAWDNB DCP No. Rev. Page YES NOh IDCN NO. DCN TRACKINd NO. DCN NO. DOCUMENT REY.
semanem Cannomia Emeen Canpeny S. ASo.113ee
/ j SNEET NO. REV, UNIT ($) oo. Ass Doc. ocLAss tour.
SO12ues+i DOCUMENT NO. @ tWA r 1 2/3 H N/A l
q DOCUMENTTITLE SYSTEM SOFTWARE REQUIREMENTS OPECIFICATIONS DESIGN CHANGE NOTICE (DCN)
COVER SNEET N STATION SYSTEM DES 6GNATOR SPA
- 1. DESCRIPTION OF CHANGE $
]EFORE AFTER QSFOUND }DD INTERIM
@NFORMATION ONLY As part of the SCE DRMS Software Evaluation Pmjed, (Software Evaluation Report, SCE No. 90400), deficiencies in some sadst DRMS Software documents were identified and documented in DRMS Softwat Evolustion Anomaly Repotts S). This DCN coneds deficiencies in the subjed document that were identif,31 ln the following SEARS:
- SEAR 03, Adion item 2
- SEAR 46, Adion item 1
- SEAR D4, Action item 1
- SEAR 0 Action item 2
- SEAR 52, Adlon item 1
- SEAR 25, Adion item 1
- 8 EAR 53, Adion item 1
- SEAR 30, Adlon item 1
- SEAR 90, Adion item 1
- 8 EAR 31, Adion item 1
- SEAR 91, Adion item 1 e
- 8 EAR 33, Actioit item 1
- SEAR 112 Adion item 1
- SEAR 34, Adion item 1
- SEAR 122, Adlon item 1
- 8 EAR 45, Action item 1
- SEAR 130, Adion item 1 AUG2' 81997 INmATING DOCUMENT (NCR, SPR, other) DRMS Gottware Evaluation Report, No. 90400 M 4LECOM
- 2. OTHER APPECTED DocutEENTS POR DCNs oNI.Y):
0 YEs 4. NO CmeR ArrtettoDoCaAaENTs Exist Ane AM taitooNrosta 2s e02 M source DoCiAaENTis ioEarnriED As FoLtows:
O was DCN: eR O werou.ew aDocsMENn O YES 4 NO Dets >>. DCNs.PActarrt,Ro RAu oR,RoceDU=st invEs STAR,AA ER O YES % NO MNummA um ms.m 2m m BEEN mMDWnNM NM F APPLICASLE, UsT TECP96 CAL JusliPICATION SOL.5tCE DOCLMENr >&MSER.
C YES $ NO PIRE PRO 1ECT10N issues APPLY (DOCRAAENTED ON PostA 2s-292 APC INCLUDED WUH M sCURE DOCLAAENT).
O YES $ NO E9MRODNENTE QUErlCADON Baut APPLY Fm wNTED oN FCW M 403 MC NCLUDED WMH source DOCUMENO.
O YES $ NO OMR MPEMNte DOctadENTATION (estnutstens, etcj ?
O YES $ NO As Powo copcmON CODFWBAAllON PiELD WALMDOWN MQUEEED7 WALMDOWN PEfrCfBAED 9YlDATE
- 3. scE DEstGN APPROVALS:
& 0 ORIGINAT DATE OTHER DATE k -
Uh
~ Eh0%p REVIEW ENGINEER DATE OTHER DATE mk e ne A.W _ 88 4 % 7 FIRST UNE SU *ERVISOR DATE OTHER DATE SECOND UNE &bPERVISOR - DATE OTHER DATE
- 4. CCWVERSION:
CONVERSION TO DCN DATE M- N A -
/ / CDM-SONGS 6R CDM-ENGINEEEb SUPPORT t s n tn.' anv i one y gn, g g g n g s g re g oo y
PAGE 2 OF f8 (For IDCNs Only)
DCP NO REV PAGE Southern CalWornie Edison Company IDCN NO. DCN TRACKING No. DCN NO. DOCOMENT REV.
- s. ABG-11366 j g NT No. sgEETNo.
DEstGN CHAN NOTICE (DCN) REV.
SUPPLEMENTAL PAGE S O123-606 1 1 . 1 DESCRIPTION OF CHANGE @BEFoRE C AFTER OAs-FoVND ADD D inTERiu OINFoRMATloN oNLY The following information refleds the before mange to sedion 3.3. Perfomunce Requirements of the System Software Requirements Spedfications.
3.3. Performance Requirements '
3.3.1. Downstream communications link loading The following performances are based on a standard speed of 38400 bauds. To get correct response time, the DU shall be able' to scan up to 2 slaves, and simultaneously to update i slave DU per second.
We assume that the slave responds within 30 ms after receiving the request, and that the master watts 50ms before sending another message.
We can define a critical (minimum) polling time according to the configuration :
b CriticalPollingTime= (NbSlaves+Nbboslaves*2) /4
PAGE 3 OF YO (ForIDCNs Only)
DCP NO REV PAGE southern CalNornie Edison kwpeny IDCN NO. DCN TRACKING NO. DOCUMENT REV.
- s. ,
Agg.11m DCN N0. j j UMENT No. SHEET NO. ~REV.
DEClON CHANO oTICE (DCN)
SUPPLEMENTAL PAGE SOizm11 1 DESCRIPTION OF CHANGE sEFORE AFTER INTERIM CAsFOUND [ ADD INFoRMATioN ONLY The following infomr" >n reflods the man 0es made to sodion 3.3. Pedormance Requirements of the System Sonware Requirements Spedfestions.
3.3. Performance Requirements _ f
% v # - ,
The LPU shall perform acquisition, measurement calculation, alarm actuation and I historical trend update on a < real-time > basis. This means that the LPU shall be able to perform its acquisition cycle every 3 seconds.
- h The DU shall perform the acquisition, disp, lay and alarm actuation on a < real-time >
{
basis. This means that the DU shall be able to poll measurements from a slave at a certain rate which is discussed in the next sub-sections.
A
__ - ~ x _
3.3.1. Downstream communications link loading
'w' _
The following performances are based on a standard speed of 38400 bauds. To get correct response time, the DU shall be able to scan up to 2 staves, and simultaneously _
to update 1 slave DU per second.
We assume that the slave responds within 30 ms after receiving the request, and tha' the master waits 50ms beform sending another message.
We can define a critical (minimum) polling time according to the configuration :
Criti calPo111ngTime= (Nbalaves+NbDUalaves
- 2 ) /4
PAGE 4 OF d (ForIDCNs Ordy) ocP NO REV PAGE southern california Edison Cesapeny IDCN NO.
DCN TRACKING NO. DCN NO.
8- ABG 11M ,l ,
1CUMENT REV. 6 DOCUMENT No. SHEET NO. REV. '
DEsl0N CHAN OTICE(DCN)
SUPPLEMENTAL PAGE SO12611% 1 DESCRIPTION OF CHANGE sEFoRE OAFTER As FoUND CADD INTERIM INFORMATioN ONLY The following :nformation refloats the before change to sodion 2.4. Gerwral Constraints of the System Software Requirements Specifications, t
2.4. General Constraints Refer to IEC-880, to the Software Quality Assurance Plan [4] and to the Verification and Va'idation Plan [5),
it has to be easy to connect any computer to the system by using the lesident communication structure. The system must include facilities for redundant configuration (from the communication or from the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS. Only the on-site maintenance computer will be Lble to modify channers configuration.
The syttom has to implement standard communication interfaces as RS485 or RS232, as well-known communication protocol as MODBUS/JBUS, The software shall be designed and implemented to maintain software logic and data as separate and distinct modules.
Communications between software programs for data transfer or program control shall be symbolic (instead of absolute) so that all programs are operated as independent utilts.
2.5. Assumptions and Dependencies Refer to the Software Development Plan.
ses z.un =v i JKJG764n% fj % Pth E % 7 0 !3 Wds E
PAGE 6 op $$'
(FC7IDCNs Onty)
DcP NO RFV PAGF southern CasIfornie Edison Company IDCN NO. DCN TRACKING NO, DCN No. DOCUMENT REV.
- S-ABer11360 ,j p
" SHEET NO, REY.
DEsloN CHAN oTICE(ocN) ht SUPPLIMENTAL par,t SO12N11 he (I d
1 DESCRIPTION 0/ CHANGE CBEFoRE @ AFTER CAS-FoVNo CADD C INTERIM C INFoRMAT1oN oNLY The following information refier:s the changes made to secilon 2.4. General Constraints of the System Software Requirements Spedfit:stions:
2.4, General constraints Refer to IEC-890, to the Software Quality Assurance Plan [4] and to the Verification and Validation Plan [5).
it has to ta easy to connect any computer to the system by using the resident commanication structure. The system must include facilities for redundant configuratior.
(fr.m the communication or from the detector point of view).
Parameter change shall not be possible on 1E cf 'inels using the DAS. Only the on-site maintenance computer will be able to modify L , anne!'s configuration.
The system has to implemerd standard communication interfaces as RS485 or RS232, as we!Lknown communication protocol as MODBUS/JBUS.
The software shall be designed and implemented to maintain software logic and data as separate and distinct modules, f Communications between software programs for data transfer or program control shall ta symbolic (instead of absolute) so that all programs are operated as independent units.
- C V e l
2.4.1, software Expans!tn capability l
4' The DRMS shall accommodate potential system growth. Since the system topology may be modified through changing values in Parameter Tables (no software changes required), the initial software shall be limited in stre to allow expansion. The following two tables define the j initial software size constraints. j 4 n _~ -
l 2.6. Assumptions and Dependencies l
Refer to the Software Development Plan.
eW&Tff&#sf.!Wi%&t%d"efdeW
PAGE b OF O (FC]IDCNs Ordy)
DC A NO REV PAGE
, southwn CalWorrde Ed6 son Company IDCN NO. DCN TRACKING NO. DCN NO.
l .. - ~.. ...a i. ... . ,ain m e S. . ABG 11M6 ,l .
O1CUMENT REV.
DESIGN CHAN H No. REV.
$UPPLEMENTAL PAGE OTICE (DCN)
SO12N11 hg;1 1 l
sEFORC AFTER AS-FOUND DESCRIPTION OF CHANGE @ ADD D 'witaiu O INFORIAATloN ONLY The following information is in Sedion 2.4. Software Expansion capabisity of the System Software Requirements Spedfications.
This INSERT A to pope 12. y Q-
- Permanent Memory Used by Software Type Software # Release Executable Size Total memory % used DU/ Base 660 8 64 kB 126 kB EPROM 42 %
DU/Appli 661 1 164 kB 266 kB FLASH 00 %
LPU/ Base 562 E 29 k6 126 kB EPROM 23 %
LPUSO 631 C 40 kB 266 kB Fl. ASH 16 %
LPU/ PIPS 664 E 76 kB 266 kB FLASH 30%
j LPU/SAS 6G5 J 120 kB 266 kB FLASH 47 %
LPU/Si 663 H Li kB 266 kB FLASH 20%
l
' RAM Memory Used by Software Type Devios # Release Memory used Total RAM memory % used DU/Appli 860+661 S+1 111 kB 266 kB 43% )
LPUSO 662+631 E+C 96 kB 266 kB 36%
LPU/ PIPS
- 662+664 E+E 99 kB 266 kB 39%
LPU/SAS 662+666 E+J 146kB 266 kB $7%
LPU/Si 662+563 E+H 99 kB 266 kB $9%
Note: The LPU/SAS uses the remaining memory to store specta in its intomal database. More memory me sotware uses, less speera me LPu/SAS can reocre.
A_ .A }
~~
im=mmmm.m
PAGE U OF N (ForIDCNs Ordy) bcp No REv pas Southem Calfomie Edison Cz;r.; IDCN NO. DCN TRACK!NG NO. DCN No. I W 'UMENT REV, l s. Ato.1126 ,j l g NN- , H NO. RN l DESIGN CHAN oTICE (DCN) l suPPLEMsNTAL Pact Sol 2 N 11 1 DESCRIPTION OF CHANGE @ssFons AFTsR AsFoUND INTsRIM CADD INFORMATION ONLY The following inhetion reflects the before change to sodion 2.2. Produd Furwalons of the Systuu Software Requiremerts Specifications:
l 2.2. Product Functions The Radiation Monitoring System is able to acquire radiation information from different kinct of detectors, it displays this information locally, and centralizes all the measurements into a DAS system.
Here are the functions that the system will perform:
LPU functions (detectork
. Acquire a measurement from a detector, and generate a standard unit result.
. Detect increasing area radiation levels (dose rate, volumic activities),
. Memortze activity levels and events,
. Physical, electrical and virtual checkouts,
. Permanent self checidng and diagnosis functk.as
. Network communication with extemal command management QU blDllkt0.L14Bl!EYil00L'
- Provide alarms and level indications (sound, lights, analog recorders),
. Display measurements,
. Route sample flows, gas or liquid through a sampling assembly.
. Memortre. events.
. Permanent self-checking and diagnosts functions
. Network communication with extemal command management c%MM*)iaW,@ Taas'A,',21EM
PAGE k OF N (F;J IDCNs Onfy)
DCP NO REV PAGE _
southern California Edison Company IDCf 4 No. DCN TRACKING NO. DON NO. DOCUMENT REV.
mm 8+ ABG-11366 ,, l j D CuMENT No. i SHEET NO. RtV.
DEslGN CHAN 40TICE (DCN) surPLEMENTAL PAGE SOf2MOS 1104 l d 1 DESCRIPTION OF CHANGE CsEFoRE @ AFTER AsfoVNo Oroo O '"Traiu O '"roau^tio" o"'v The following information refleds the changes made to sedion 2.2. Produd Fundions of the System coftwarnr Requirements Spedfir.ations:
2.2. Product Functions The Radiation Monitoring System is able to acquire radiation information from different kind of detectors it displays this information locally, and centralizes all the measurements into a DAS system.
Here are the functions that the system will perform:
LPU functions (%tector):
Acquire a measurement from a detector, and generate a standard unit result.
Detect increasing area radiation levels (dose rate._volumic actMties) _
j .
u*morire activity levels and e<ventsf(WOTE: LPU setpoint changes or other hatabase chant,es are not storeti)
. Pnysical, electrical and virtual checkouts.
Permanent self-checking and diagnosis functions Network communication with extemal command management DU functions (displav unit):
Provide alarms and level indications (sound, lights, analog recorders).
. Displey measurements.
. Route sample flowf. gas or lic uld throuah e samplina assembiv.
Memorire eventsf{ NOTE: ^ LPU setnoint changes or other database changes are (not stored.) - -
Permanent self checking and diagnosis functions Network communication with extemal command management l
l l
l ses nma sev s ***
CTS O T MtidYNthS IcooE NsY7N?
PAGE l OF N8 (F;7IDCNs ONy)
DCP NO REV PAgg Southern CalWornie Edloon Company IDCN NO. DCN MKING No. DCNNO. DOCUMENT REV.
S- ABG 11366 j j SH U NO. RW.
DEsl4N CHAN NOTICE (DCN) 6012N11 C SUPPLEMENTAL PAot 1 DESCRIPTION OF CHANGE . SEFoRE AFTER As#oVND CADD [ INTERIM C INFoRMATioN oN'.Y The following information refieds the before change to sedion 3.1.3.3 Processing of the System Software Requirements Spedfiestions, page 17:
3.1,1.3. Processing The LPU has different functions:
. Manage the detector and acquire measurements.
. Run a special algortthm to calculate an elaborated result.
Memorize the historical trend and the event summary.
Answer to the requests that are received from the two communication links. -
Check its own software and hardware routinely.
. Manage the analog input (if installed).
I
- * " " " " ' ~
unune.m; sum wn,w
- ~ -
PAGE 10 OF M (ForIDCNs Only)
DCP NO REV PAGE souttiern California Edlen Company IDCN NO. DCN TRACKING NO. DCN NO. DO UMENT REV.
- s. ABG 11366 ,
(@eN) DOCUMENT No. SHEET NO. REV.
DEclGN CHANGE NOTICE (DCN) ( g SUPPLEMENTAL PAGE i DESCRIPTION OF CHANGE CBEFoRE @ AFTER As-FoVND CADD ] INTERIM [INFoRMATioN oNLY The following infoNnation reflects the changes made to sedion 3.1.3.3. Processing of the System Software Requirements spedficatior.A. page 17:
3.1.3.3. Processing The LPU has different functions:
e Manage the detector and acquire measurements.
e Run a special algorithm to calculate an elaborated result. y- _ _ + _
e Memorize the historical trend and the event summary)(NOTE:, LPU setpoint e
[ changes or other database Changes are not stored.) p - ~
Answer to the requests Inst are receivea from tne ww communicatioli links, e
Check its own suttware and hardware routinely.
Manage the analog input (if installed).
l act .41764 NEW 8 M6 C T A16G pen ( D
PAGE II _ OF 45 (FCIDCNs Oth)
DCP NO REV PAGE Southern CalWotnia Edison Company IDCN NO. DCN TRACKING No. DCN No. DOCUMENT REV.
mm N
8 ABG 11366 ,} j DOCUMENT No. SHEET NO' l DESIGN CHANGE NOTICE (DCN) q/ REV' SUPPLEMENTAL PAGE SO12N110 1 DESCRIPTION OF CHANGE @sEFoRE C AFTER [As-FoVND CADD INTERIM INFoRMATloN oNLY The followin0 information reflods the before change to the Table of Content of the System Soft varo Requirements Specifications, page 3:
Table ofcontent
- 1. Introd uction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Purpose . . ... . . ..... .. .. . . . . . . . .. . . . . . . . . ... . . .
1.2. Scope...........................................................................................................6 1.3. Definitions, Acron 1.4. References ..........yms and Abbreviations .......................................
......8 1.5. Overview........................................................................................................9
- 2. General Description ....... . . . . . .. . . . . . . . . .. . . . . .. . .. . .. . .. . ... . ... ..... .
2.1. Product Perspectives . .. . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . .. .. ..
2.2. Prod uct Functions..... ... . .. .. . . . . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . .
- 2. 3 U ser Characteristics . . .. . . . . . . .. . . . . .. . . . . . . . . . . . . . . ... ..... . ... . . . . . .. .
2.4. Ge ne ral Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. ... . . ..
2.5. Assumptions and Dependencies ........................................... ....................... 12
.......................12 SCE 201794 IEW 3 446 1 WUO8tAF08MBv4DO vor C3 00 00 emt40 CMTDATAAS31130s\179 (GEW 76 2,01611DAT toviD .1.0000 8eted C7/2347
PAGE E _ OF N (For IDCNs Onfy) 4 DCPNO REV PAGE Seethern CaMornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
.u.. ......anan....n.... S. . ABG.11366 - f 1 N DocuMEP:7 NO. SHEET NO* RE'V-DE&l0N CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE SO1N11 1 DESchlPTION OF CHANGE [stFORE @ AFTER ASFoVND [ ADD [ INTERIM O INFORMATION ONLY r
The following information refieds the changes made to the Table of Conteid of the System Software Requirements Specifiestions, page 3:
)
l Table ofcontent
- 1. Introd uction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 1.1. Purpose..................................................................................
1.2. Scope............................................................................................................6
.......................7
- 1.3. Definitions, Acronyins and Abb.eviations ...........................
- 1. 4 . R ef e re n ce s . . . . . . . . . . . . .. . .. .. . . . . . . . .. . . . . . . . . . . . . . . . . .
1.5, Overview..................................................................................................
- 2. General De s cription . . . . . . . . . . . ....... .... . . . . . . . . . . . . ... .. . . . . . . . . . . . . . .. . . . . . . . . . .
2.1. Product Perspectives . . .. .. .. .. . .. . . . . ... . . . . . . ... . . . . . . . . . . ... . . . . . . . .... . . . . .
2.2. Prod uct Functions . .. ... . . ... . . .. . . . . . . . . . . . . . . . . .. . . . . . .. ...
2.3. U ser Chara cteristics . . ... . . . . .. . . . . .. . . . . . . .... .12. . . .. . . . . . . . .
2.4. Gar'eral Constraints.. .. . . ....................................... .12 L2.4.1. Software Expansion Capabilit 2.5. A ss umpsons una ve,=m nces . ........ .y . .......... ....... ......... . .... .. .. .. ............. ..... ]
..r.......................................................
1 p
1 4
SCE 341764 M V 3 446 7 W OstMostdSwEDO ver 03 00 00 4r17963 C6T A%ASC11300\17k(GEtt 79 2.03 kJ12 DAT DevtD .
PAGE 19 OF U (ForIDCNs bNy)
DCP NO REV PAar southern CalWotnia Edison Company'lDCN NO. DCN TRACKING NO. DCN NO. .
DOCUMENT REV.
NW6064de8106 8* ABG 11366 j j ENT NO. l DESIGN CHAN SHEET 'NO. REV.
OTICE (DCN)
SUPPLEMENTAL PAGE S012N1 1 h 1 DESCRIPTION OF CHANGE CDEFORE C AFTER [AS-FOUND CADD C lNTERIM [lNFORMATION ONLY The following information refieds the before etiange to the Appendix sodion of the System SoRwere Requirements Spedfications, page 5:
3 . 5.1. Se cu rity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
- 3. 5.1.1. Fauh detection . .. . . . . . . . . . . . . .. ... . .. . . . . . .. . . . .. . . . . . ... . . . . . . . . . . . . . . . .. . . ... . 4 5 3.5.1.1.1. Machine instruction level .................................... 45 3.5.1.1.2. Code module levol.............................................. 45
- 3. 5.1.1.3. Audit level . . . . . . . .. . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . .. . .:. . . . . . 46
- 3. 5.1.1.4. Syste m le vol . . . . .. . . .. . . . . . . . . . . . . . . . . . . . . .. .. . . . . . . . . . . .. .. . . . . . . . 4 7 APPE N DIX A Standard pa rameter table.............................................................. ............ 48 M b
o PAGE Ik 0F Y0 -
(ForIDCNs Onty)
DCP NO REV PAGE Southern CalWornia Edison Company IDCNNO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
8- ABG 11366 j j N DOCUMENT NO' 1 SHEET NO.
DESIGN CHANGE NOTICE (DCN)
REV.
SUPPLEMENTAL PAGE SO126110 -
1 DESCRIPTION OF CHANGE C8EFORE 3AFTER [AS-FOUND [ ADD [ INTERIM ]INFORMATION ONLY The following information r2flects the changes made to the Appendix of the System Software Requirements Specifications, page 5:
i
- 3. 5.1. Se cu rity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 3. 5.1.1. F a ult dete ction . . . . . . . . . . . . . . . . . . . .. . . .. . . . . . . . . . . . . . . . .. . . . . . . . . .
3.5.1.1.1. Machine instruction level .................................... 45 3.5.1.1.2. Code module level.............................................. 4 5
- 3. 5.1.1.3. A u dit le vel . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . .. . . ... . .. . . . . . . . .. . . . . 46
- 3. 5.1.1.4. System level .. . .. .... ..... ... . .. ... .. . .. . . . ... . . . . . . . . .. . . .. . .. . ... 47 APQ5:h!hlX.A Standard paramatar table _. ... ......... ............................._ ..m .48 A P'P s N DlX4sta nDa rd pa~ra meie r ta blie . . ... . .. . ..!... ... .. .;. ....... .. . .. ....r.. . . .. .. .. ....
APPENDIX C Standard parameter
_ table......................................................... .................
SOE 241782 NEY I '90 w,-cwe 2 .10000 a o ... u C7124'51 x u . %
C LETDATA401136411798,c.w.fivlD14 DAT P'etes
PAGE d OF N (Fer IDCNs Or$)
DCP NO Rgv pAgg Southern Catfornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO.
- -
- - Ano.iim _ 1 iUMENT REV.
N DOCUMENT NO- I' q SHEET NO.
REV.
DEslGN CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE SO12S40611 h 1
- t AFTER DESCRIPTION OT CHANGE @stFORE [As-FOUND CADO [lNTERIM [INFORMATION ONLY The followin0 information is in the Appendix sodion of the System Software Requirements Specification, page 46.
msnm,A me.+-d e==_^_ &
mispeelee het steef9sen EpeeMe RMepteseeees Men Te Afee seeW9sen ee puteressamt ein I sin Ostisel e G Genefel samml Nm "_ *_ '
3 N esameegetemI emmstem Agasse bt
.=. ' E G4ennelmassegne e __ l_ __ _
1 Teelemy agenten ie '
N "
, .' "J melleenense W '
es senspeedegemetem
.*% si 6 E L h bl
' g l N L=uL") mentenenee Vehmi -- ^ - M shfnelM esenflen J W .
se 50 last sulese only etesses degelfte se ileftal seentstem) p We a es lit i4M M See W eld 6 M M WY i lW . r hu bles '
des commen e gesll4m een sueless *
' , no Opossesenet i immeem
' e '
mes ** sig pessmetes Tse mael i emeem i
i see ees 5mgest anypuntse me '
ees GeneselMala iI i fel eimmstese LsN! hM i
W '
W MM de1I I 15 eIsasIWWo I*=
- L"")
7W i 7W HM i4e II nM ,PU""3 Ebene oftm ei __ Zl-_^ . a poematose WB e7e
. - , n-
!m 'gg LPUEJ F1M tessaugment seese T_ _ __
EEPROM)
URR ,
ldi\ l s : *. . =% - e*
E1l opApm i i liefselShake ese a f lI WimmelShielen ages I ,
i
_)
j l ' usereDeeplemen .
=
LPU Amulesen teve geeeetlen "J 4 c1 o E7 I i l tingsfeest asemens esos p, =J i, AngueGen feste eInoneneeste i
- aq em To be ani . , i i egenteeneeneI Ane esas yeem enenges B i i i t _'_ __ _ Z mfIIneste seen geem teegeney
= Geflehene BefWilste esas ee....a w ,
n ,, ,
W
' I fI M 8 Eg L=J""J e/;i Unestesesessnehen system este se i 4'ei Dauemia IIBMesse J_ ._. . Late sei i 7t RAaneet em seemtehen I-3 etim es )
Plategette SWIItseen i Issin Stannelfilegemenese Geefee Une etsitie 7J si i i
,PJ ei.d, ii i l estenses thenne steesseemesti sesefte ,PJ 6 .,wer - y,,' f es l l i o i ,3 ., ,. ,,
3- ,PJ Rees estly ms I 1 = MN 3estem es i M eessenes L."L'""J i 't M sene y,q i
m . * *u - Une tu I) '
s I' ..
LNte 15 )) 'y , WM este Spec I c le LPWDU figeene tim one see k solmed to tie LPU urit, wie Ste eWier t tie DU.
Speems to Unt sneens tiet tio pommetere are speens to each tiing et LPU er DU unR.
Speems to LPU means test tio esos le speems to the LPU (unuesd Ipy fie DU). ' I speems to Du means met me afee is speems to the Du tunused spy me LPU).
speces to me System means that parametere are sommen to se me unne (DU er LPu).
1 eCe M 17M MV 3 446 T 2 ver c3 oc 00 eases C c-_ me -m gems y,Df,03 TAwoo113esuMSA Dat 40io.icooo m me c7a457;
PAGE O or of (ForIDCNs Orsy)
Dcp NO REV PAGE Sawthorn Calfornie talleen Company IDCN NO. DCN TRACKING HO. DCN NO. DOCUMENT REV.
- s.
SOONP ~
Aso iim _1 1 DOCUMENT No. i SHEET N'O' RtV' Deal 0N CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE 8012N11 [
r 1 DESCRIPTION OF CHANGE BEFORE @ AFTER CAs.FOUND CADD C INTERIM CINFORMATION ONLY ,
The following information is in the Appendix sedian of the Syslam Softwart Requirements SpecNiostion, page 46.
$PPENDiLA Rtandard parmanator taksim non re ==e ev =me mm ames== ammes imus= =.em Mi Per Gesser r su Gaham e e emanal molem neuerius Iie W W essesIsmalesammstem " '"
' Angsee h 1m in Geones mal misemam essenweems I Tasm arensimen .. .
enseemsend -- .= =J eisteensnes 1st 135 Es .'a.6- *- Assemsten , h4 ase vuess namee inuma mesmoinas eseman L- m meneensnm ne masser
.amese inpa sommise) mi i m asse mer eso no saw anses ei em as ases mess une esa emer , i neewee 4aso ten answanu mesn u sun see .. ....m- : ~ , i L, ii opememanal uno us --
ammi iemm
~
l'. -*e j T(.7. .'
- V "-. ,
li pommeere aso isse Te um ammt som ,
'IWWeiI amnistem SWIEm anylinese mD le85 GensW mess' s mIgni elemelse Iw . . Lre Assess h We .__
r_- _ =
r use e i n- - _
W 1575
- - ~
I sWMN MN ,P'." _ '
.
- rs p. ~
1mp .
truieu rm messesmemmes _-__
enPRDie at asse - e er- - ua meses amenaeres ei im mee 1- + x - l nas mesmssheen ene ,
mu usare seen seen ,
- f'"
=
tyv mandenen anus ensemusa
- s. s.uc.s r... . - , =_i e =_a
- , .-, asammmen omassi neuens ses em e menssensame oss eiusessen eem ens une a em Tobe se '
asse -__ x ami nem mes seem seness esem esquerer osamuis namesser ena ,
o.
a o assi . : .c. . ,,, w ., .
E. i Wl emIW @iM W BM sen et, '
eias ;asseslen L- T se I , ,
- osu nes en sen seenemen mi em esas se - , sem mesu ist c .x_ i- - , a masasnsoms ion ei uun e i _
I'>
AtI y 11 , insmiliennr r imuns um seem ,
n ;soeums uJ si i W I > meanseiemmensi e o se i ,
e o. .e .v ,3.sr?.~ .
- .pg,4; ". s ,c. .a c . 3
, aa as i as , asem.,amannemsee . ' . s e. c .ti ? .mJ nues ady as '
me ,
es sesumwr ,,,.
essem 1se ,
se enssom _
Let ou e e i' ...me -
. . ;. ua o ic. ,
~m. ..sw c n,u;.'* .... uns i ,, , emmenenannam mes W I C to LPUfDU Insoft 9is see one le feWed to Ste LPU ist, med 9 e steer e tio DU.
speams to una mesne est em poemeters we sposmo te oesh Wnd of LPU er DU una.
speans specesto te DuLPumoreennene that the eseis that sp.. ein see is DU A the et ",% 6emeed to the by toLPU LPU).6 mused by em DU).
sesens to the #rstam meene that commates me sammen to es the unas (Du er LPU).
c INSERT A, B, C, D and E X __. >
C 30 1 0t ,b od $7hth
_ . ~ . _ . - _ _ _ _ . _ . _ . , _ _ . . _ _ _ _ . _ _ . _ . _ _ ,
_ ,, ,y ___
(ForIDCNs Only)
OcP NO REV PAGE 4
i southern CalWornie Edison Crp, IDCN NO. DCN TRACKING NO. DCN NO.
> 8- A8G 11306 j DOCUMENT REV.
j i 990NP DOCUMENTNO. '*
DEsteN CHANet NOTICE (DCN) SHEET NO' MlEV' SUPPLEMENTAL PAot 8012 6 11 1 DESCRIPTION OF CHANGE #Eroat O^r75a"O'*rouao Z^oo D '*ria'a g O INFORMATION ONLY This 4,v,ert is added in the Appendix section of the System Software Requirements Spedfgations.
NSERT A APPENDIX-B Events laaned to the DU Event Table I
secoun each oode ha as own meaning, every ninese mnt must han en exclusive code number whatever unit generates the event.
! Note:
LPU Database changes made locaNy through a DU are Og logged as Ennts in the DU or LPU event tables, it database changes att made v6a tlw (AASS, these events are logged to the MASS event flie only.
Code l W--ion
" DU. GenerelStasus Aff*'- I
_1 Unit w 2'a status 2 H ; we status __
3 Software si.e.;
4 DU sect 6c status i
5 Monitor status 6 .. 9. Reserved DU. #ardeere Fam4 Kvener 35 Ana!M 'aa? =~-M*h marhanism fault 36 Fles enemory fault (w - '--_= or erase)
' 48 RTC lai*H~* fault 49 h* allocation fault 50 Screen sumory fault i l 51 Display initia;issuon fault 52 10 Maa-arian or soeuencer fault 53 Slave data Wa= fault i ,4 laternal ascoesstaa escuencer fault j $$ Norwerk ca== mad Fault i
56 j Error when reedias slave's matic information
$7 K:A, 4 fault 4 ,,
, S-s _,,... e,r.,
, 59 Alarm r 4dus fault 60 latemal historical trend fault 6i Analos loput or ~_d=M fault k[ 62 External voi.,.i coaunand fault A -
_ A e
g gyg g
_ . _ _ _ _ _ _ _ . ~ _ _ _ _ _ . _ . _ _ _ _ _ _ _ . -__
m_ -- - _ - -
- PAGE ff OF 48 (ForIDCNe Only)
DCP NO REV PAGE Southern Cahfornie Ed6een Campany IDCN NO. DCN TRACKil40 NO. DCN NO. DOCUMENT REV. I 4
spess>
8 ooCUMENT NO.
. ASS 15m .1 1 SHEET NO' REV' DE860N CHANGE NOTICE (DCN)
SUPPLEMENTAL PAQt 5012 6 11 z% -
1 DESCRIPTION OF CHANGE O *eroaa O ^rTia OA*rouwo E^oo O iw'naiu Diaroau^ tion ow'v This insert is added in the Appendix sew 60n of the System Software Requirements SpecNications.
INEERT5 Code Meanten DU.Enmuelan er Inserrier E* esses l 100 NMIintemst' watchdos failed down d 101 Un.ased 102 Exception : sero dh'idon l
1 103 Exosotion : tms uror 104 8-M" : address entw los Exception : overflow-106 E=ew : no init intemet l 117 F-Mon : parasit intemet i los NMIintempt : Pomwfail appear 109 NMIintemet : Powerfall disappear DU. Cemenend AcAnendedre Ensues i
120 l---" reconnlu l lurernel Events 150 Du start L 151 DU stop l
f 200 Unused DU. P\nremeter Feuer Events (
201 Parameter fault (value is out of ranae)
, DU. NetherA CF"M*" Evenid l 250 Corununicatico chip receiver.tammine 251 Recalved Assee too lona 252 485 link immuned in transmission anode DU. Other Events
{ 230 I Base or applicatios sonware invalid sim 300 DU. SeB= ore t '-- M nrece) ReenreedErsats t Tracen
}l j 301 Tracel
__ L 1
., fA 1
. M 7
. ~ ,_._._ ,_ . _ _ . - _ _ _ . . _ _ _ . , _ __ .. - _ _ _ _ . . _
PAGE 14 OF 46 (ForIDCNs Oriy)
DCP No REV PAar m Camornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO. ,g DopENT REY.
. . . . . . . . . . . . . . . . - - . . S. ABG 11366 B 5 M DOCUMENT No. i SHEET NO. REV.
DE860N CHANGE NOTICE (DCN)
D I* h h
! $UPPLEMENTAL PAGE DESCRIPTION OF CHANGE Ost' oat ^'T5a **rouwo B^oo O '"T5a'a O 'a'oau'rioN ow'v This inaeit is added in the Appenatx section of the System SONware Redulfements SpecNiostions.
IN8ERT C T ,
APPENDlX-C Events Looned to the LPU Event Table secause each code has its own meaning, every singie event must have en exclusive code number whatever unit generstes the event.
f Note: LPU Database changes made locawy through a pu are agt logged as Events in the DU or LPU event tables, it database changes are made via the MASS, these events are logged to the MASS event file only.
1 Code l Mession _
LMI. GmeeralSteams Medi/loemen i Unit operatine status 2 Hardware status l 3 ScAware status 4 Acouisition fault status 5 Monitor status l 6 .. 0 Reserved LM1- Alann Stanus Channel Changing 10 Alarin channel A II Alarin channel B 12 Alarm channel C 13 Alarin channel D 14 l 25 Alann channel P LPU. Nardware res* Evaser p 30 Fault on CM Board P!A ctdp 31 Fault on CM Board PTM ctdo
/
_ 32 P0ter anator startinuit (CM PIPS) i 33 Fiher anator stop thult (CM PIPS) 34 TW au sWve Alter advance 35- Anales taput aconsition inschanism fault 36 Flash toetnory fault GR,s- M or erase) q.l 37 Spectrum acomsien teemory fault
/
- ' ~ " " ~ c A"en m y a da % ra:i n ,
I PAGE O OF N (For IDCNs Only)
DCP NO REV PAGE Southern Cellfornie Edison Cr;n, IDCN NO. DCN TRACKING No. DCN No. DOCUMENT REV.
S- ABG 11M j j M
DOCUMENT NO. SHEET NO. REV.
DESIGN CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE SO12N11 2 ne. 1 DESCRIPT10N OF CHANGE CBEroar O^rTra O^*<ouwo E^oo 'NTERIM INFORMATION ONLY This insett is added in the Appendix sodion of the System Sonware Requirements Specifications.
INSERT D v l Code Meanian 38 Not used j
39 Tinneout DU Alter advance autori'a'_% fault 40 Countina fault on A detector (CM PIPS) 41 C-a'iaa fault on 8 detector (CM PIPS)
}
42 LPU IC : 2 volts fault 43 LPU IC : pressace cienber test fault 44 IEU IC : 12 wits fault 45 LPU IC : 5 volts fault i 46 LPU IC : init stabilization ranse fault 47 LPU IC : Offset adnastament fault l
48 RTC laitiallantion tsult 49 Memory allocation fault
~
50.64 Reserved 65 Five successive reboots of the unit fault 66 LPU IC : *****'ve hiah voltase power =taalv fault 67 LPU IC : positiw hiah voltaae power supply fault 68 LPU 10 : VIA chip fault LPU. !=n er *r; ,;Evenes 100 l NMI interrupt: watchdaa failed down 101 Unused 102 F==='an : sero division
(
103 Exception : bus error f 104 Exception : aditaas error 105 Funentiaa
- 9WrSow' 106 Exception :notaitlaterrupt 117 Fwesswinn parasit laterrupt
{
108 Interrupt NMI : Powerfail aaaaa+ I 109 laterrupt NMI : Powerthil see LPU Comumend AN '^ t: Events 120 lCrummand renanaN LPU. InneneelEwents g\
(f 150 151 LPU start LPU stop [
C A f .
19 6 7Q4
PAGE M OF N (ForIDCNs Only) bcp No agv pang sevehorn CeNIornie Edloon C:rp.i IDCN No. DCN TRACKING NO. CUMENT REV.
l S. , ABG 11W DCN No. l 119044 DOCUMENT NO. /1 SHEET No. REV.
DESIGN CHANGE NOTICE (DCN) 4' SUPPLEMENTAL PAGE k DESCRIPT10N OF CHANGE O *aroan O ^ m a O^*rouwo E^oo O wTia'u O lN'ORMATION ONLY This insert is added in the Aprendix taction offhe Avsle_ni Software Requirements Speciflosilons.
3 - - - x x - - m , _ _ _ . -
INSERT E Meanter
/ Code 161 Futer advance on init 162 Periodic futer advance f> 163 Delta o sda Siter advance <
164 Delta o max Ahor advance I 165 Max owentina Sher advance f 166 Futer advance ce external command l 167 Futer adv== on udnimum flow 168 Futer advance on mavimuun Sow 169 FDier advance on and of exterrnal test or Stanby 4,
170 Electrical test aroes countina value i 171 Opucal test sees annatine value 180 LPU/IC: rante transition 181 Unused 182 LPU/IC: An peridic chamber test is initiated
{
183 trU/IC: An peridic aihet adinarment is initiated i
T 184 U'U/IC: An offset agustment due to a temperature variation isinitiated .
185 LPU/IC: start spectSc initialization f> 186 LPU/IC: and spectSc initinhzation LPU/SAS: Not enough counting has been found in I I 190 the reference peak 191 LPU/SAS: Specarum's resolution has been found as I too poor l 192 LPU/SAS: Energy variation fouowing energy h ,
w.i.cdon is too high 193 LPU/SAS: Hardnre gsn correcuon has been done k sher reference pr:ak deviation.
194 XRANGE ALGORTlHM: ranse switch LPU.PIsresussr Femer Kysuser 200 Unused Paranneter fault 6alue is out of ranae) f 201 LPU. Network r= Hee Ennsts I 250 ramnunticeuon chtp receiver jammina 251 Received frame toolons
\ 252 485 hak Januned in transmipaion mode
(
/ tPU. I Other Evenes f 280 Base or application softsste invalid size LYJ.SoRwere Debaarhnt tt.ece) Reserved Events
=
300 Trace 0 301 Tracel cEt dINPt'd$ 7ecoE%%d[.7
PAGE 1% OF (0 ,_
(ForIDCNs Orty) bcP NO REV PAGE Southern CeHfornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO.
DQCUMENT REV.
- s. ABG.11366 ] l UMENT No. SHEET NO.
DCON CHAN OTICE (DCN) REV.
I SUPPLsMENTAL PAGE S0123406 11 k 1 DESCRIPTION OF CHANGE DEFoRE O ^rTra O^$<ouwe ^oo D i"Traiu O lNFoRMAT1oN oNLY The following information refieds the before diange to Sedion 3.1.7.1 Introdudion of the System Software Requirements Spedfications, page 23:
3.1.7. Command management 3.1.7.1. Introduction This is a mschanism to send commands to the device throJgh the regular communication functions (read or write words in the communicaton table). RMS devices do not use MODBUS specific command functions because of the modularity the system must have. Indeed, it is possible to add a communication extension board to address the parameter table directly without using the intomal protocol, the command process has to work in a transparent mode.
f
mn u or w (ForIDCNs Only)
DCP NO REV PAGE mn CalWornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO. -
S* ABG 11366 j DOCUMENT REV.
j
" SH NO.
DESIGN CHANO OTICE (DCN) d ( RE9.
suPPLsMENTAL PAGE SO123406110fl 1 DESCRIPTION OF CHANGE Omeroat B ^rTaa OAsFouND [ ADD C INTERIM INFoRMATioN oNLY The following information refieds the changes made to Sedion 3.1.7.16ntroduction of the System Software Requirements SMcations, page 23: l 3.1.7. Command management 3.1.7.1. Introduction This is a mechanism to send commands to the device through the regular communication lynr+iana tramef erMc words in the communication table). RMS
~
devices (onip ufe KOQBUS read /wnte] functions because of the modularity the system must have Indeea, n is possue w add a communication extension board to address the parameter table directly without using the intamal protocol; the command process has to work in a transparent mode, l
- n"n ** * ' ~ c W M a M ey EYt?.O TooE*'Ns?$1AS W
PAGE M OF M3 (FJIDCNs Orvy)
DCP NO REV PAGF Southern California Edison Company IOCN No. DCN TRACKIN3 NO. DCN NO. DOCUMENT REV.
S- ABG 11366 j j DESIGN CHAN OTICE (DCN)
/ (1 SHEET N . RW.
sVPALEMENTAL PAGE SO123-006 1 1 t} j DESCRIPTION OF CHANGE X BEFORE C AFTER CAs-FoVND ] ADD INTERIM INFoRMATioN oNLY The following infonnation refieds the before citange to Section 3.1.7.3.3. Output emulation mode of the System Software Requirements Specifications, page 26:
3.1.7.3.3. Output emulation mode By running the output emulation command , you can simulate 'ferent system states, it is possible to Generate up to 20 test steps that will run after each acquisition.
This mode is disabled automatically when all of the 20 steps have been executed.
m 25"N ev 8
- e&WffJ"f##hQuMPtfdd%444%EE*
FF @D U (ForIDCNs Only)
DCP NO REV PAGE teuthern Camornia Edison Company IDC"' NO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
- s. ASG 11366 j '
M DOCUMENT No.
DESIGN CHANot NOTX E SCN) SHEET NO RE9' buPPLEMENTAL PAGE 8012 6 110 1 DESCRIPTION OF CHANGE CsEFORE @ AFTER ASf0VND [ ADD C WTERIM [INFORMATION ONLY The following information evnects the changes made to Section 3.1.7.3.3. Output emuletion mode of the System Sonware Requirements Spedfloations, page 26:
8.1.7.8.3. Outputemulaten mode By running the output emulation command , you can simulate ctflerent system statesh LP N is poseble to generate up to 20 test steps that wiu run after each acquisition.
, x m ,- p r e r e ,-
This CommBRd is only iffg34emented in LPl.1 softwares.
e_1 _- _-f _w This mode is disabled automatically when all of the 20 steps have been executed.
b h
PKGE7 074D (ForIDCNs Only)
DCP NO REY PAGE Southern CalWornie Edison Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
- s. ABG 11366
] j
/ SHEET NO. REV.
DEaHIN CH TICE (DCN)
S01236061 1 3
SUPPLEMENTAL PAGE 1 DESCRIPTION 0F CHANGE @aEFoRE O ^rTra ^$<ouwo O^oo O lNTERIM INFoRMAttoN oNLY The following information refieds the before change to Sedion 2.3. Usef Charadertstka of the System Software Requirements Spedfications, page 12:
2.3. User Characteristics
. The computer system (maintenance computer and supervisor) checks any manual input for syntactic correctness and semantic plausibility;
. The user is able to check the basic system functions on-line (Self-diagnosis reporting, voltage values, intemal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal operation mode (Acquisition, alarm reporting...).
. The computer system reports its own defects and failures to the operator (possibly through the communication link).
2.4. General Constraints Refer to IEC-880, to the Software Quality Assurance Plan (4) and to the Verification and Validation Plan (5).
It has to be easy to connect any computer to the system by using the resident communication structure. The system must include facilities for redundant configuration (from the communication or from the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS. Only the on-site maintenance computer will be able to modify mannel's configuration.
The system has to implement standard communication interfaces as RS485 or RE?12, as well-known communication protocol as MODBUS/JBUS.
2.5. Assumptions and Dependencies Refer to the Software Development Plan.
e k % F # 3. # if d !I M % E N " 4%?iNF
, y...... g g-(ForIDCNs Only)
DCP NO REV PAGE sevewra CalWornia Edison Company IDCN NO. DCN TRACKING NO. DCN NO.
DOCUMENT REV.
- s. ASG 11366 ,j j D CuMENT No. SHEET NO. REV.
DEsteN CHANO oTK:E (DCN) suPPLaMawTAL PAos 5012N11 4 1 DESCRIPTION OF CHANGE stFORE AFTER CAsfoVND @D C INTsRIM CINFoRMAT10N orJLY Tit) following information reflods the changes made to Sedlon 2.3. User Charadertstics of the System Software Requirements Specifiestions, page 12:
2.3. User Characteristics
. The computer system (maintenance computer and supervisor) checks any nanual
_ input for syntactic conectness and semantic &usibility; _ _ ,- _ -
~ ' ' ' '
. Par'anieter changes using the DU or the MASS can'only be done if the operator enters the right password. The MASS shall support multiple levels of password protection. These levels are described in the [11] MGPl MASS SRS 45224. r
. The user is able to check the basic system function 6 on-line (Self-diagnosis reporting, voltage values, intomal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal operation mode (Acquisition, alarm reporting...).
. The computer system reports its own defects and failures to the operator (possibly through the_ communication link). _
z
+ , . - . - - -
. The MASTshall provide a user's friendly interface to allow the configuration of LPU and DU, All data specific to one function shall be displayed on a single screen.
_1 ^
= 2 J
2.4. General Constraints
_ -,_ , m %
Refer to [3] IEC 8801988, to the Software Quality Assurance Plan ([4] MGPI-SQAP.
45203) and to the Verification and Validation Plan ([5] MGPI-SVVP 48120).
_. A m_ - _
s to be easy to connect any computer to the system by using the resident communication structure. The system must include facilities for redundant configuration (from the communication or fmm the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS. Only the ord site maintenance computer will be able to modify channers configuration.
The system has to implement standard communication interfaces as RS485 or RS232, as wel6 known communication protocol as MODBUS/JBUS.
(ForIDCNs Ordy)
DCP NO REV PAGE southern Catfortda Edison Company IDCN No. DCN TRACKING No. DCN No. DOCUMENTREV.
- s. AEG 11366 ,j j N SHEET No.
DESIGN CH 0TICE (DCN) /) fiEV.
SUPPLEMENTAL PAoE NI2 I*I h i DESCRIPTION OF CHANGE @stFoRE AFTER O^*rouwo O^oo 'wTraiu DiaroaurrioN ow'v The following information refled the before change to sodion 2.4. General Constraints of the System Software Requirements Spedfications, page 12:
2.3. User Characteristics
. The computer system (maintenance computer and supervisor) checks any manual input for syntactic correctness and semantic plausibility;
, . The user is able to check the basic system functions ordline (Self diagnosis reporting, voltage values, intomal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal opers' ion mode (Acquisition, alarm reporting...).
. The computer system reports its own defects and failures to the operator (possibly through the communication link).
2.4. General Constraints Refer to IEC-880, to the Software Quality Assurance Plan [4] and to the Verification and Validation Plan [5).
It has to be easy to connect any computer to the system by using the resident communication structure. The system must include facilities for redundant configuration (from the Communication or from the detector point of view).
l -
I Parameter change shall not be possible on 1E channels using the DAS, Only the on-site maintenance computer will be able to modify channel's configuration.
The system has to implement standard communication interfaces as RS485 or RS232, as welRnown communication protocol as MODBUS/JBUS.
= = = " "
- e = M O M Aj! W % 8 % 3",03 TefaF
, p n, g (FC21DCNs OrWy)
- bcp No arv PAar I
) Sevehern Caspernis Edison company IDCN No. DCN TRACKING No. DCCUMENT REV.
- s. , A8G.11 M6 DCN No. j j
D CuMENT No. SHEET NO.
DESIGN CHANS OTICE (OCN) ) AEV.
SUPPLEMENTAL PAot SO12N11 1 j INTsRIM DESCRIPTION OF CHANGE CBEFORE @AFTER CAMoVND [ ADD [INFoRMATioN oNLY The following information reflect the danges made to section 2.4. General Constraints of the System Software q Requirements Spedfloations, peGe 12:
i 2.3. User Characteristics q e The computer system (maintenance computer and supervisor) checks any manual input for syntactic correctness and semantic plausibility;
! e The user is able to check the basic system functions online (Self-diagnosis
- reporting, voltage values, intamal tests...)
Manual action (from communication) shall not delay basic safety actions in normal
) .
j- operation mode (Acquisition, alarm reporting...).
l . The computer system reports its own defects and failures to the operator (possibly
! through the communication link).
l 2.4. General Constraints Refer to IEC-880, to the Software Quality Assurance Plan [4] and to the Verification and l
Validation Plan [5).
It has to be easy to connect any computer to the system by using the resident communication structure, The system must include facilities for redundant configuration
' (from the communication or from the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS, Only the on-site maintenance computer will be able to modify channers configuration.
The system has to inclement standard communication interfaces as RS485 or R3232, as well-known communication piviecci as MODBUS/J8US.
r N n , , -
The software shall be designed and implemented to maintain software logic and data as separate and distinct modules. . A _ 2 e " - - -
l C 1 f[ fM7dMN[
PAGE N OF NI (For IDCNs Or#) . j ber wo arv PAos Southern caifornie Edinen Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
j j I S* ABG 11386 Nal0N CHAN OTICE (DCN) uMENT NC. f p SHEET NO. MEV.
suPPLaMsNTAL PAGE 8012 6 11 % 1 DESCRIPTION DF CHANGE @ stFoRa O APTsn AsfouND CADD D inTiaiu iwroauAriou outv The following i@rmation pfled the before chenee to section 2.4. General Constralfts of the System Software Requirements Spedfloations, page 12:
2.1. User Characterlatica
. The computer system (maintenance computer and supervisor) checks any manual input for syntactic conectness and semantic plausibility;
- The user is able to check the basic system functions on-line (Self diagn'osis reporting, voltage values, intomal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal operation mode (/ Ntion, alarm reporting...).
. The cons 'ter system reports its own defects and failures to the operator (possibly th ough the communication link;.
2.4. General Constrainta Refer to IEC-880, to the Software Quality Assurance Plan (4) and to the Vertrication and Validation Plan (5).
It has to be easy to connect any computer to the system by us!ng the resident communication structure. The system must include facilities fot redundant configuration (from the communication or from the detector point of view).
Paremeter change shall not be possible on 1E channels using the DAS. Only the on-site maintenance computer will be able to modify dannel's configuration.
The 6, stem has to implement standard communication interfaces as RS485 or RS232, as =:: twr, communication pidwes: as MODBUS/JBUS.
The software shall be designed and implemented to maintain software logic and data as asperate and distinct modules.
.E _
IM g7 g i
l
PAGE SI 0F M (FuIDCNs Ordy)
Dcri NO REV PAGE Southern Cailfomia E414een Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT MkV.
Se ASG 11366 _j )
Ota60N CHANo oTicE(DCN) '
8012N11 )
SUPPLEMENTAL PAGE 1 DESCRIPTION OF CHANGE Ostroa E art 5a O^*rouwo ^oo O in75a'u O'wroaMATION oNLY The following information reflect the changes made to section 2.4. General Constraints of the System Sonware Requirements Spoolflest60ns, peDe 12:
2.3. User Characteristica
. The computer system (' maintenance computer and supervisor) checks any manual input for syntactic correctness and semantic plausibility; q
. The user is able to check the basic system functions on-line (Self diagnosis reporting, voltage values, intomal tests...)
. Manual action (from communication) shall not delay basic safety actions in normal operation mode (Acquisition, alarm reporting...).
. The computer system reports its own defects and failures to the operator (possibly through the communication link).
2.4. General Constrainta Refer to IEC 880, to the Software Quality Assurance Plan (4) and to the Verification and Validation Plan [5).
It has to be easy to connect any computer to the system by using the resident communication structure. The system must include facilities for redundant configuration (from the cornmunication or from the detector point of view).
Parameter change shall not be possible on 1E channels using the DAS, Only the on-site maintenance computer will be able to modify channel's configuration.
The system has to implement standard communication interfaces as RS485 or RS232, as well-known communication protocol as MODBUS/JBUS.
The software shall be designed and implemented to maintain software logic and data as separate and distinct modules.
- v r -
Communications between software programs for data transfer or program control shall 6
be symbolic (instead of absolute) so that all programs are operated as independent units.
m & A A A -
c % % oS 5 d i~N N Yd-N Tocen"N M E 2
[ PAGE 3 b NI (ForIDCNs Orty)
DCP NO REV PAGE Southern Calllornie Edison Cm IDCN HO. DCN TRACKING NO. DCN NO. DOCUMENT PEV.
, 4825im j j
""' SHEET NO. REV.
DEslGN CHAN OTICE (DCN)
SUPPLEMENTAL PAGE 8012N110 id . 1 DESCRIPTION OF CHANGE @DEFoRE [AFTER As-FouND ADD INTERIM INFoRMAT1oN oNLY The followin0 information refieds the before change to section 3.1.7.1. Introdudion of the System Software Requirements Spedfloations, page 23:
3.1.7. Command management 3.1.7.1. Introduction This is a mechanism to send commands to the device through the regular
' communication functions (read or write words in the communication table). RMS devices do not use MODBUS specific command functions because of the modularity the system must have, indeed, it is possible to add a communication extension board to address the parameter table directly without using the intamal protocol; the command process has to work in a transparent mode, ekTJMaMruiM%dQ'MTJAW
g (Fct IDCNs Ordy)
DCP NO REV PAGE Southern California Edison Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT REY.
an ynias nr.ir a, r o m an,e sinne r S. ABG-11366 j j UM NT No. SHEET NO. REV.
DESIGN CHAN OTICE (DCN)
SUPPLEMENTAL PAGE D I2 O l*1 .M 1 DESCRIPT'ON OF CHANGE BEFoRE @ AFTER As-FoVND [ ADD INTERIM INFoRMATioN oNLY The follcwing information refieds the changes made to sedion 3.1.7.1. Introduction of the System Software Requirements Specifications, page 23:
L 3.1.7. Command management 3.1.7.1. Introduction This is a mechanism to send commands to the device through the regular communication functions (read or write words in the enmmunication table). RMS 3 (devices only use MODBUS read /wnte functions t>ecause _of the modulanty the system; J must nave, inoeeo, a is possible to aoo a communication extension oo m to aaaress
( the parameter table directly without using the intemal protocol; the command process has to work in a transparent mode.
m E
'M JL m ..
PAGE N - OF N5 (ForIDCNs Only)
DCP NO: REV PAGE I
Southern CalNornia Edloon Company IDCN NO. DCN TRACKING NO. DCN *: ; DogUMENT REV.
S- ABG 11366 ] I DOCUMENT No- 9 sHGT NO. REV.
DESIGN CHAN NOTICE (DCN)
SUPPLEMENTAL PAGE E12 1*l i
1 DESCRIPTION OF CHANGE @BEFoRE AFTER As-FoVND ADD INTERIM
]INFoRMATioN oNLY The following information refieds the before change to section 3.3.2. CPU performance of the System Software Requirements Spedfications, page 42:
3.3.2. CPU performance The system software includes a function that computes the actual CPU load. The result of this function is accessible through the communication table, and is updated after each acquisition cycle. Tnis is the CPU load as a percentage of maximum capacity. To perform this function, the CPU measures the duration it spends waiting the next acquisition (this is done after the last acquisition process),
s The total CPU load shall not exceed 60%, else a status fault is declared.
3.3.3. Memory chW C".# = ?&yre %; m ,a,,,n% g 1
N PAGE N (ForIDCNs Only)
DCP NO REV PAGE southern Califo/nia Edison Company IDCN NO. DCN TRAnKING NO. OCN NO. DopVMENT REV.
S- ABG-11M l 4 DEslGN CHAN OTICE (DCN) dfl " "'
SUPPLEMENTAL PAGE SO123-806-1 1 0' 1 DESCRIPTION OF CHANGE BEFoRE AFTER As-FoVND O^oo INFORMAT1oN ONLY OINTERIM The following infonnation reflects the dianges made to section 3.3.2. CPU performanoe of the System Software Requirements Spedfications, page 42:
3.3.2. CPU performance The system software includes a function that computes the actual CPU load. The result Cf this function is accessible through the communication table, and is updated after cach acquisition cycle. This is the CPU load as a percentage of maximum capacity. To perform this function, the CPU measures the duration it spends waiting the next ccquisition (this is done after the last acquisition process).
.: ;g , ,- , - , -
i If the LPU detects that the cycle processing time exceeds the cycle time as defined by
( the configuration, a fault is reported in the unit status.
. m 3.3.3. Memory 9
P l g yg g ggg g { gy y 4W l
\
PAGE M OF N (ForIDCNs Only)
DCP NO REV PAGE Southern California Edison Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMEl4T REV.
S. ABG-11366 q j
EET No. REV.
DESIGN CHAN OTICE (DCN)
SUPPLEMENTAL PAGE SO12MS1 1 r[ 1 AFTER [As-FouNo DESCRIPTION OF CHANGE @BEFORE CAoD [ INTERIM [INFoRMATioN oNLY The following information refleds the before change to sedion 3.1.1.1. Introdudion of the System Software Requirements Specifications, page 13:
3.1.1.1. Introduction All the RMS devices have several digital communication links. The communication protocol is MODBUS / JBUS and the transmission speed is by default 38400 bps.
The protocol has to be fully compatible with JBUS (as defined by EPRI) and with MODBUS (as defined by MODICON). This protocol, as used by MGP instruments, is described in the RMS Protoco! Technical Specirication document le).
MODBUS protocol allows communications between a master station and up to 247 slave stations, using point-to point or multidrop connections. There is only one station, the master, that is allowed to start an exchange. Each station must have a specific i address on the network (slave identifier). I This protocolincludes the following communic' uon functions: !
3.4 Read N words from the slave memory.
6 Write 1 word in the slave memory.
16 Write N words in the slave memory.
8 Communication diagnosis function (code 10 to 18).
11 Event counter reading. {
It accepts the writing diffusion capability: Possibility to write the same data to all the slaves at one time by using the address 0 (no response). ,
l The transmission speed is setup by software and must include the following speeds:
9600,19200,28800,38400,57600 and 115000.
1 Some limitations because of lack of processing power may be defined as :
57600 speed on maximum two communication links.
. )
115000 speed on maximum one communication link (for testing purposes only). l The physicalinterface has to conform with the RS485 or RS232C norm.
" " *** cisArME#nk'dNPe'.48 foooE"JAN TdE4F
PAGE S u op g (ForIDCNs Ordy)
DCP NO REV PAGE Southem CalNornia Edhoon Cn;ny IDCN NO. DCN TRACKING NO. DCN NO.
- DOCUMENT REV.
s.
ABG.11366 ,j f DCONcH OTicE (DCN)
SUPPLEMENTAL PAGE SO1N11 h 1 DESCRIPTION OF CHANGE sEFoRE AFTER As-FoUND IN1 TRIM INFoRMATioN oNLY DADD The following information refieds the changes made to sodion 3.1.1.1. Introdudion of the System Software Requirements Spedfications, page 13:
3.1.1.1. Introduction All the RMS devices have several digital communication links. The communiition protocol is MODBUS / JBUS and the transmission speed is by default 38400 bps.
The protocol has to be fully compatible with JBUS (as defined by EPRI) and with MODBUS (as defined by MODICON). This protocol, as used by MGP instruments, is described in the RMS Protocol Technical SpectRcation document \8}.
MODBUS protocol allows communications between a master station and up to 247 slave staticns, using point to-point or multidrop connections. There is only one station, the master, that is allowed to eart an exchange. Each station must have a specific address on the network (slav entifier}
This protocol includes the followirig communication functions:
3,4 Read N words from the slave memory.
6 Write 1 word in the slave memory.
16 Write N words in the slave memory.
8 Communication diagnosis function (code 10 to 18).
11 Event counter reading.
It accepts the writing diffusion capability: Possibility to write the same data to all the slaves at one time by using the address 0 (no response).
The transmission speed is setup by software and must include the following speeds:
9600,19200, 28800, 38400, 57600 and 115000.
Some lirnitations because o, Mk of processing power may be defined as :
. 57600 speed on maximum two communication links.
. 115000 speed on maximum one communication link (for testing purposes only).
This speed limitation of 57600 for two links shall not be included as software limitation, but only as configuration limitation. It means that there should be no skid to be configured with two links at 115000 on the same device. . . .
e __ _ - _ - -y The. physi::alinterface has to conform with the RS485 or RS232C norm.
cSEMUES doi %$ food"MJf&
__ _ a
(For IDCNs Only)
DCP NO REV PAGE Scuthern California Edison Company IDCN No. DCN TRACKING NO. DCN NO. DOCUMENT REV.
S. ABG.11366 j j
- DESIGN CH NOTICE (DCN)
SUPPLEMENTAL PAGE D UMENT No.
MI2 l'I (i SHEET NO. RIV.
1 -
AFTER DESCRIPTION OF CHANGE @BEFORE As-FoVND ]Aoo C INTERIM INFoRMATioN oNLY The following information refieds the before change to sedion 3.1.5.3.3. Degradd mode of the System Software Requirements Specifications, page 21; 3.1.5.3.3. Degraded mode in the following case:
. Critical parameters are not valid (integrity)
The unit transfers the defruit parameters from the FLASH memory to the parameter table, and goes in degraded mode. This is signaled in the unit status and reported in the event summary.
The critical parameters are checked periodically by the software.
When a parameter is out of range the fault is sigiialed in the software status.
To exit the degraded mode the operator needs to:
- 1. Go to maintenance mode.
- 2. Read the event summary to locate where the error is.
- 3. Correct the error by writing a new parameter, or by restoring parameters from FLASH memory.
- 4. Go back to normal mode (see 3.1.4.3.2).
c W TWoMcTrysPthEfa# O M @
OF M PAGE M (ForIDCNs Only)
DCP NO REV PAGE Southern CalNornia Edison Company IDCN NO. DON TRACKING NO. DCN NO. DOCUMENT REV.
l M
S-ABG 112 j ]
DOCUMENT No.
DESIGN CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE SO12N11 p SHEET NO. REV.
1 j 1 DESCRIPTION OF CHANGE SEFoRE AFTER As FoUND 300 INTERIM INFoRMATioN oNLY The following information reflects the dianges made to sodion 3.1.5.3.3. Degraded mode of the System Software Requiremerts Spedfications, page 21:
3.1.5.3.3. Degraded ma in the following case:
Critical parameters are not valid (integrity)
, ,mex ,
- ~ -
The unit user 'he copy r. -r .;itical parameter that is stored in FLASH memory instead of using the pameters from the network memory and goes in degraded mode. This is
- * ^
signaled in the unit
- - > status~ and reported in the event x
summary.P' ---
The critical parameters are checked periodically by the software.
When a parameter is out of range the fault is signaled in the software status.
To exit the degraded mode the operator needs to:
- 1. Go to maintenance mode.
2, Road the event summary to locate where the citor is.
- 3. Correct the error by writing a new parameter, or by restoring parameters from FLASH memory.
- 4. Go back to normal mode (see 3.1.4.3.2).
ses ame nev =
MMa'#2*n*?&'JMPddsfood"AN'MfSP
PAGE h OF M0 (For IDCNs Oriy)
DCP NO REV FAGE Southern California Edison Company IDCN NO. DCN TRACKING NO. DCN NO.
l S- , ABG 11366 ,
j DQ OUMENT REV.
SHEET NO. REV.
'l DESIGN CHAN OTICE(DCN)
SUPPLEMENTAL PAGE 12 1*l '- 1 AFTER it;TERIM INFoRMATioN oNLY DESCRIPTION OF CHANGE @BEFoRE CAs-FoUNo CAoo ,
The following information reflects tiie before change to sedion 3.2.2.5 Power supply monitoring of the System Software Require,ments Spedfications, page 39:
3.2.2.4. Hardware watchdog A hardware watchdog has to detect any system matfunction. The software resets periodically the watchdog. If the microprocessor locks up or if there is a software problem, the hardware watchdog has to reset the entire unit. It may also signal the default by activating an alarm relay.
See 3.5.1.1.3. for more details about watchdog control.
3.2.2.5. Power supply monitoring The system has to be informed of all power supply faults since they Itave to be reported in the event summary table. Wher ", voltage reaches a certain low level, the microprocessor must receive an in' ,.oon, and must have enough time to perform interruption process (around 100 s).
We don't have to save data memory because of battery backup.
Each unit also controls its power supply voltage by reading the value from an analog to digital converter. If voltage level is abnormal (user's define thresholds), the unit signals the fault.
sa w: nov.a w g=ggygpgfy"gTgy/
PAGE M OF (For IDCNs Only)
DCP NO REV PAGE Southern Canfornie Edison Company IDCN NO. DCN TRACKING No. DCN NO. DOCUMENT REV.
- s. ABG 11366
, j j M DOCUMENT No. SHTET Nb. REV.
DEalGN CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE 2 N 1-1 1 DESCRIPTION OF CHANGE BEFoRE Q AFTER AsfoVND 3DD INTERIM C INFoRMATioN oNLY The following information refieds the manges made to sedion 3.2.2.5. Power supply monitoring of the System Software Requitwnents Spedfications, page 39:
3.2.2.4. Hardware watchdog A hardware watchdog has to detect any system malfunction. The software resets periodically the watchdog. If'the microprocessor locks up or if there is a software problem, the hardware watchdog has to reset the entire unit. It may also signal the default by activating an alarm relay.
See 3.5.1.1.3. for more details about watchdog control.
3.2.2.5. Power supply monitoririg The system has to be informed of all power sucolv faults since they haua 'n ha reportad in the event summarv table the power supply goes down, there should be a reserved '
@r to keen the avata alive so the nower fail can be correctiv managed. They microprocessor must receive an interruption, and must have enough time to perform interruption process (around 100 ps).
We don't have to save data memory because of battery backup.
Ea:1 unit also controls its power supply voltage by reading the value from an analog to digital converter, if voltage level is abnormal (user's define thresholds), the unit signals the fault.
cla Tw G i % dI M % % foooPiE!i'E S E
UAGE TA W TS-DCP NO REV. PAGE Southern Calgornie Edison Q IDCN NO. DCN TRACKING NO. DCN NO, DOCUMENT REV.
5 : :f :: ^r^: "^?::: . 222:
- O 11300 ,
119eNP DOCUMENT No. 'I SHEET NO. itEV.
DESIGN CHANGE NOTICE (DCN)
SUPPLEMENTAL PAGE p
l DESCRIPTION OF CHANGE sEFoRE C AFTER As-FoUND @D INTERIM INFORMATioN ONLY The followine info mation refieds the before diange to section 3.1.8.3.1. Output management of the System Software Requirements Spedfications, page 30:
3_1,8.3. Processing 3.1.8.3.1. Output management Each device has several outputs:
A DU has 5 relay outputs to command extemal alarms, up to 16 outputs to command extemal components (pumps, valves...) and 3 relay outputs to command check sources.
A LPU has 2 or 3 relay outputs (depending on the option) to report extemally the unit state (fSutte e alarms).
To command rep.,. relays, the unit uses its intamal status as alarm levels, processing modes, faults.
On the DU there are 16 possible power outputs to manage, it is possible to use an automation process that is included in the DU software to command them automatically.
By using commands, or a screen on the DU, it has to be possible to force the output manually in a certain state (on or off ), or to put them back in automatic mode.
To be able to manage a screen that will display the outout state, and that will change them J. rough the network, a special mechanism has to be implanted even when the DU is not directly wired to the skid.
E C T ( Q O
PAGE N OF %d (ForIDCNs Only)
DCP NO,, Agy. pAgg southern Calgornie Edison Company IDCN HO. DCN TRACKING NO. DC N NO. DOCUMENT REV.
- 8* ABG-11366 j j NT No.
DEalGN CHANG OTICE(DCN) SHIEY N . REV.
l SUPPLEMENTAL PAGE E N 1*1 -
1 DESCRIPTION OF CHANGE CsEFoRE @ AFTER - As FoUND ADD IN"ERIM ]INFoRMATioN ONLY The following information reflods the dmnges made to section 3.1.8.3.1' Output management of the Sys.em Software Requirements Specifications, page 30:
3.1.8.3. Processing 3.1.8.3.1. Output management I Each device has _several outputs: __
~
y , -- - - , , __
AD U has 5 relay outputs to command extemal alarms, up to 16 outputs to A- t f('o_. command extemal components (pumps, valves...L K LFU has 2 or 3 relay outputs (oepenaing on the option) to rep h extemally the unit state (faults or alarms).
To command report relays, the unit u'ses hs intamal status as alarm lovsis, pre.1ssing modes, faults.
On the DU there are 16 possible power outputs to manage, it is possible to use an automation process that is included in the DU software to command them automatically.
By using commands, or a screen on the DU, it has to be possible to force the output manually in a certain state (on or off ), or to put them back in automatic mode.
To be able to manage a screen that will display the output state, and that will change them through the network, a special mechanism has to be implanted even when the DU is not directly wired to the skid.
9 N M
(ForIDCNs Ordy)
DCP NO 7EV PAGE Southern CalNornia Cdison company IDCN NO. DCN TRACKING NO, DCN NO. DOCUMENT REV.
8- , ABG 112 g j j DESIGN CH OTICE(DCN)
. SUPPLEMENTAL PAGE SO12N11
[
i SHEET NO. REV.
1 DESCRIPTION OF CHANGE @BEFoRE AFTER ASFoVND @D INTERIM C INFoRMA*'oN ONLY The following information refieds the before change to sodion 1.4 Refeiences of the System Software Requirements spedfications, page 9:
1.4. Referinces (1) ANSillEEE Std 729-1983 IEEE Standard Glossary of Software Engineering Terminology.
(2) ANSillEEE Std 8301984 Guide to Software Requirements Speci6c61%ns (3) lEC 880-1986 IEC Standard for Software for computers in the safety systems of nuclearpowerstations, (4) MGP-SOAP - 45203 RMS Software Quality Assurance Plan (5) MGF .WP - 48120 RMS Software Veri 6 cation and Validation Plan (6) MGP SDP -45202 RMS Software Denlopment Plan (7) MGP-GRS - 45254 RMS General Requirements Speci6 cation (8) MGP-Protocol ST - 45866 Embedded protocol technical speci6 cations (9) MGP-LPU.SRS - 45180 General LPU Software Requirements Specification (10) MGP-DU SRS - 45182 DU Software Requirements Spec.'fication I
O IM M M Q $7Q
(For IDCNs Only)
DCP NO REV PAGE Southern Califorrda Edison Company IDCN NO. DCN TRACKING NO. DCN NO. DOCUMENT REV.
S. ABG-11366 ,) ]
DESIGN CHAN OTICE gDCN)
SUPPLEMENTAL PAGE SO12N1 1 / 0[
SHEET,NO.
REV.
1 DESCRIPTION OF CHANGE BEFORF @AFTER ]AS-FoVND ADD INTERIM INFokv'.1oN ONLY The following information refieds the changes made to sedion 1.4 References of the System Software Requirements Specifications, page 9:
1,4, References (1) ANSillEEE Std 729-1983 IEEE Standard Glossary of Software Engineering Terminology.
(2) ANSillEEE Std 830-1984 Guide to Software Requirements SpeciScations (3) lEC 880-1986 IEC Standard for Software for computers in the safety syste_ms of nuclearpower stations.
- m _ _ _ _ _ v (4) MGP-SQAP - 45203 _ RAMSYS Softwcre Quality Assurance Plan l
(5) MGP SWP -46120 RAMSYS Software Verification and Validation Plan (6) MGP-SDP - 45202 RAMSYS Software Development Plan l
f l7) MGP-GRS - 45254 RAMSYS GeneralRequirements SpeciRcation l [8] MGP Protocol-ST-45866 RAMSYS Embedded protocol technical speci6 cations (9) MGP-LPU-SRS - 45180 General LPU Software Requirements Specification (10) MGP-DU.SRS - 45182 DU Software Requirements Specification (11) MGPi-MASS-SRS-45224 MASS Software Requirements Specification
+ v -
l su 26-1N m 3 446 i
i e$T aBI1 e f,N 7 4 l