ML20246G978

From kanterella
Jump to navigation Jump to search

Forwards Functional Requirements Matrix,Similarity Document & Description of Continuing Plant Safety Monitoring Sys Verification & Validation Program Accompanied by Graphical Representation of Program,Per 890510 Request
ML20246G978
Person / Time
Site: Beaver Valley, Vogtle, 05000000
Issue date: 07/07/1989
From: Sieber J
DUQUESNE LIGHT CO.
To:
NRC OFFICE OF INFORMATION RESOURCES MANAGEMENT (IRM)
References
TAC-64577, NUDOCS 8907140292
Download: ML20246G978 (19)


Text

{{#Wiki_filter:_. -- e g Beaver Valley Power Station Shippingport PA 15077-0004

                           ^

i JOHN D SIEBER (412) 6G5502 Vice Prengtent - Nuclear Operations i July 7, 1989 U. S. Nuclear Regulatory Commission Attn: Document Control Desk Washington, DC 20555

Reference:

Beaver Valley Power Station, Unit No. 2 Docket No. 50-412, License No. NPF-73 Plant Safety Monitoring System (TAC 64577) Gentlemen: Your letter dated May 10, 1989 documented the results of the NRC Staff's audit of the Beaver Valley Power Station Unit 2 (BVPS-2) Plant Safety Monitoring System (PSMS) and requested that information be submitted to resolve PSMS Verification and Validation (V&V) Program open items. Enclosed are copies of the Functional Requirements Matrix (Attachment A) and the Similarity Document (Attachment B). Also included as Attachment C is a description of our continuing V&V Program accompanied by a graphical representation of the program. As discussed during the audit, the similarity table was prepared using Plant Vogtle since Plant Vogtle equipment more closely matches the DLC PSMS. Tests that are referenced as being i performed on South Texas to satisfy the functional requirements q were also applicable to Plant Vogtle. j 1 Validation testing was performed on the PSMS during our recent l refueling outage. The test procedure used was developed by an  ! independent group following the functional requirements matrix and I development decomposition. Various PSMS discrepancies were i corrected during the first refueling outage under Design Change 1 Package DCP 891. Validation testing was then performed using a test proceduce developed by an independent group, in accordance i with the functional requirements and decomposition. Performance of the validation testing resulted in the following inconsistencies: 41 Procedural deficiencies 5 Decomposition deficiencies 6 Firmware deficiencies 1 Hardware deficiencies h6 ( 4 Miscellaneous I t 2 890707 ' P $$ Eh0hlM 050004 PN 2

Benvor Valley Powar Station, Unit No. 2 Docket NO. 50-412, License No. NPF-73 Plant Safety Monitoring System (TAC 64577) Page 2 The inconsistencies that occurred during system development that were not discovered during the original software verification activities were identified during the validation - process. An example of an inconsistency involved the thermocouple junction box RTD quality coding algorithm and the manner in which,RTD's with bad quality are addressed. The unresolved inconsistencies have been an61yzed and do not present any operational deficiencies to the system The inconsistencies are documented and will be corrected by future firmware changes as necessary. The four discrepancies identified during validation. testing that were not completed will be corrected prior to restart following the second refueling outage. These deficiencies do not affect operation of the PSMS. q If you have any comments or questions, please contact me or members of my staff. Very truly yours, l J. D. Sieber A-Vice President Nuclear Group cc: Mr. J. Beall, Sr. Resident Inspector Mr. W. T. Russell, NRC Region I Administrator Mr. P. Tam, Sr. Project Manager Director, Safety Evaluation &-Control (VEPCO) 1

                                                                               )

i i

       -                                     ATTACHMENT A FUNCTIONAL RE0UIREMENTS MATRIX l

l Apolicable Requirement Aeolicable Document RVLIS Functional Requirements RVLIS.FR.001 Refer to PAMS.FR.001. RVLIS.FR.002.A Refer to plant CRDR.

                 .                         k         T     kTA display and P. VAR.13.

RVLIS.FR.003.B Refer to PAGE 2 DETAIL DATA display 4 PAGE 3 DETAIL DATA display and P. VAR.14. RVLIS.FR.003.C Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.16. RVLIS.FR.003.D Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.15. RV?IS.FR.003.E Refer to 'PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA displayand P. VAR.02. RVLIS.FR.003.F Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.02. RVLIS.FR.003.G Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.16. RVLIS.FR.003.H Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.15. RVLIS.FR.003.I Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.02. RVLIS.FR.003.J Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.01. RVLIS.FR.003.K Refer to PAGE I DETAIL DATA display and P. VAR.13. RVLIS.FR.003.L Refer to PAGE 2 DETAIL DATA display PAGE 3 DETAIL DATA display and P. VAR.14. RVLIS.FR.003.M Refer to RV LVL display and P. VAR.17. RVLIS.FR.003.N Refer to RV LVL display and P. VAR.17. RVLIS.fR.003.0 Refer to RVLIS.FR.017 RVLIS.FR.004 Refer to RVLIS.FR.003 RVLIS.FR 005 Refer to P. VAR.17 RVLIS.FR.'006 Refer to PAMS.FR.003.A RVLIS.FR.007 Refer to RVLIS.FR.004 RVLIS.FR.008.A Refer to P. VAR.17. RVLIS.FR.008.B Refer to P. VAR.17. RVLIS.FR.008.C Refer to P. VAR.17. RVLIS.FR.008.D Refer to P. VAR.17. RVLIS.FR.008.E Refer to P. VAR.17. RVLIS.FR.009.A Refer to P. VAR.17. RVLIS.FR.009.B Refer to P. VAR.17. i RVLIS.FR.009.C Refer to P. VAR.17. i RVLIS.FR.009.D Refer to P. VAR.17. l RVLIS.FR.009.E Refer to P. VAR.17.  ; l l - Y

ATTACHMEWT A RVLIS.FR.010 Refer to P.PAMS.FR.001.A. RVLIS.FR'.011.A Refer to P. VAR.017 RVLIS.FR.011.B Refer to P. VAR.017 RVLIS.FR.011.C Refer to P. VAR.017 RVLIS.FR.011.D Refer to P. VAR.02 RVLIS.FR.011.E Refer to P. VAR.01' RVLIS.FR.011.F Refer to P. VAR.016 RVLIS.FR.012 Refer to P.PAMS.FR.006 RVLIS.FR.013 Refer to P.PAMS.FR.007.A and B. RVLIS.FR.014 Refer to'P.PAMS.FR.008.A. RVLIS.FR.015 Refer to P. VAR.17. RVLIS.FR.016 Refer to P.PAMS.FR.009. RVLIS.FR.017.A Refer to P.PAMS.FR.010. RVLIS.FR.017.B Refer to P.PAMS.FR.010.E 1 s s 4 h l I l I l l l

n

                                                                               -                                                     ATTACHMENT A FUNCTIONAL RE0VIREMENTS MATRIX Abolicable Requirement                               Applicable Document PAMS Fungtional Requirements P.PAMS.FR.001.A                       Refer to EQDP ESE-53 and 53B for the RPU/DPU qualification test results. Refer to ESE-61B                               l for the plasma display qualification results.

Refer to the plant equipment qualification files for the qualification status of the'other portions of the Category I and 2 channels routed via the PSMS. P.PAMS.FR.001.8 Refer to P.PAMS.FR.001.A. P.PAMS.FR.001.C Refer to P.PAMS.FR.001.A. P.PAMS.FR.001.D Refer to P.PAMS.FR.001.A. P.PAMS.FR.002.A Refer to PSMS Technical Manual, Volume 1, Figure 1-1. (Document 2501.405-001-003.) P.FAMS.FR.002.B Refer to the plant CRDR. P.PAMS.FR.002.C Refer to PSMS Technical Manual, Volume 1, Figure 1-1. (Document 2501.405-001-003) P.PAMS.FR.002.D Refer to drawing 2032338 Rev 4 sheet 6 P.PAMS.FR.002.E Refer to P. VAR.001 : RCS Pressure (WR) P. VAR.002 : WR Hot Leg Temperature P. VAR.003 : WR Cold Leg Temperature P. VAR.004 : Steamline Pressure P. VAR.005 : PP DWST Level P. VAR.006A: Neutron Flux-Lower Range P. VAR.006B: Neutron Flux-Upper Range P. VAR.007 : Containment Hyrogen

                                                                                                                                   " VAR.008 : Containment Pressure (XR)

P.'fAR.009 : Primary Safety Valve Status

  • P. VAR.010 : SG Safety Valve Status d

P. VAR.011 : CCW Header Pressure

                                                                                                                   -               P.' VAR.012 : 'CCW Header Temperature
                                                                                                                       '           P. VAR.013 : RCP Motor Status                                      l P. VAR.014 : Hydraulic Isolators                                 l P. VAR.015 : DP Transmitters                                     l P. VAR.016 : Capillary Line RTDs                                 i P. VAR.017 : RVLIS                                               1 P. VAR.018 : Reference Junction                                  j Box RTDs                                       i P. VAR.019 : Core Exit Thermocouple                              !

, P. VAR.020 : RCS Subcooling l P. VAR.021 : Reactor Trip i Breaker Status  ; P.PAMS.FR 002.F Refer to P.PAMS.FR.002.E.  ; Refer to drawing 2031991 Rev 3 sheet 21,30 and31.

                                                                                                                                                                                                     ~

P.PAMS.FR.003.A P.PAMS.FR.003.B Refer to the PSMS Technical Manual, Volume 1, Section 2.3.(Document 2501.405-001-003) P.PAMS.FR.003.0 Refer to P.PAMS.FR.003.A I _j

ATTACHMENT A 4 P.PAMS.FR.004.A Refer to the following maintenance surveillance procedures: 2MSP-3.03-I :PSMS Input Checks of RPU A Channel III .

                                   *RJB RTDs : TE-A1,A2,A3
  • Core Exit T/Cs': TE-01,02,04,05,10,11, 13,14,15,16,20,21, 22,23,24,25,26,28, 33,34,39,40,41,47, 48,49
  • Capillary Line RTDs : TE-1313,1314,1315, 1316,1317,1318, 1319
                                   *DP Transmitters : LT-1310,1311,1312
                                   *RCS Pressure (WR) : PT-440
                                   *PP DWST Level : LT-104A3
                                   *Steamline Pressare : PT-475,485,495 2MSP-3.05-I :PSMS Input checks of RPU A Channel I
  • WR Hot Leg ~ Temperature : TE-413,423,433
                                   *RCS Pressure (WR) : PT-442
  • Containment. Pressure (XR) : PT-106A .
  • Neutron Flux-Lower Rng : NFLUXL (Tr A)
  • Neutron Flux-Upper Rng : ' NFL!JXU (Tr A)
  • Containment Hydrogen : HA-100A 2MSP-3.06-I :PSMS Input Checks of RPU B Channel II
                                   *WR Cold Leg Temperature :.TE-410,420,430
  • Containment Pressure (XR) : PT-106B
  • Containment Hydrogen : HA-100B'
                                 -*Neutron Flux-Lower Rng : NFLUXL (Tr 8)
  • Neutron Flux-Upper Rng. : NFLUXU (Tr B) 2MSP-3.04-1 :PSMS Input Checks of' RPU B Channel IV
                                   *RJB RTDs : TE-B1,B2,83
  • Core Exit T/Cs : TE-03,06,07,08,09,12,17, 18,19,27,29,30,31,32,
              .                                            35,36,37,38,42,43,44, 45,46,50,51
  • Capillary Line RTDs : TE-1323,1324,1325,
                .                                                1326,1327,1328, 1329
                                   *DP Transmitters : LT-1320,1321,1322
                                   *RCS Pressure (WR) : PT-441
                                   *Steamline Pressure : PT-476,486,496
                                   *WR Hot Leg Temperature : TE-423A 2MSP-3.07-I :PSMS Input Checks of RPU N1 .
  • Hydraulic Isolators : LIS-1310,1311,1312, 1320,1321,1322
                                   *RCP Motor Status : P-21A,21B,2]C 4

(

I i

                                           .                                                                                                            ATTACHMENT A                                   )

P.PAMS.FR.004.B 2MSP-3.03-1 :PSMS Input Checks of RPU B Channel III

                                                                                                                                                      *CCW Header Pressure : PT-150A,150B,150C          j
  • Primary Safety Valve Status:

RV-551A,551B,551C

                                                                                                                                                      *SG Safety Valve Status : SV-105A,105B,105C 2MSP-3.05 I. :PSMS Input Checks of RPU A Channel I        .
                                                                                                                                                      *CCW Header Temperature : TE-130A,130B,130C
                                                                                                                                                      *SG Safety Valve Status : SV-101A,1018,101C      ]

SV-103A,1038,103C

  • Reactor Trip Breaker Status :52-RTB 2MSP 3.06-1 :PSMS Input Checks of RPU B Channel II
  • SG Safety Valve Status : SV-102A,102B,102C SV-104A,104B,104C 2MSP-1.04-I :PSMS Input Checks of RPU B Channel IV 4
  • Reactor Trip Breaker Status : 52-RTA P.PAMS.FR.004.C Refer to P.PAMS.FR.001.A. i P.PAMS.FR.004.D Refer to P.PAMS.FR.001.A.

P.PAMS.FR.005.A Refer to P.PAMS.FR.002.E. h P.PAMS.FR 005.B Refer to P.PAMS.FR.002.E. P.PAMS.FR.006.A Refer to South Texas Project QDPS procedure DSPD.0986.0 tests 5.0 and 11.0. P.PAMS.FR.006.B Refer'to South Texas Project QDPS procedure DSPD.0986.0 tests 4.0 and 11.0. P.PAMS.FR.007.A Refer to South Texas Project QDPS procedure DSPD.0986.0 test 9.0 and 11.0. P.PAMS.FR.007.B Refer to South Texas Project QDPS procedure DSPD.0986.0 test 9.0 and 11.0. P.PAMS.FR.008.A Refer to South Texas Project QDPS procedure SPEC.1186.0 test 6.1. j P.PAMS.FR.009.A Refer to P.PAMS.FR.004. l P.PAMS.FR.009.B Refer to P.PAMS.FR.002.A l P.PAMS.FR.010.A Refer to Beaver Valley Unit 2 USAR, Figure 8.3.14 I

                                                  ,                                                                                 for the source of power to the PSMS.                                 l
                                                                                                                                                              *RPU A ,DPU A - Protection Set 1          I
                                                                                                                                                              *RPU B, DPU B - Protection Set II          !
                                                     ,                                                                                                        *RPU C         - Protection Set III
                                                                                                                                                              *RPU D         - Protection Set IV        I P.PAMS.FR.010.B                                                                       Refer to P.PAMS.FR.010.A.

P.PAMS.FR.010.C Refer to South Texas Project QDPS procedure > SPEC.1186.0 test 6.4.  ; P.PAMS.FR.011.A Refer to P.PAMS.FR.001  ! P.PAMS.FR.004 I P.PAMS.FR.005  ; P.PAMS.FR.010 ' P.PAMS.FR.012.A Refer to P.PAMS.FR.001 P.PAMS.FR.004 i P.PAMS.FR.005

ATTACHMENT B .

                                             .(pmoarison of Beaver Vallev Unit 2 & Plant' Voatle PSMS Beaver Vallev Unit 2                ht Vootle .                       i System                      *Idantical equipment                                     ,
                                   -Overview                      qualification data packages                            j
                                                                *WCAP-11340 applicable                                   1
                                                                                                                         )
                                                                *Similar hardware configuration                          i
  • Equivalent system level software
                                                                                                                         ]
                                                *Similar application a'     <ithms *Similar application algorithms (Generic design                     (Ger.eric design specifications utilized-            specifications utilized-          !

3 vs 4 loop configuration) 3 vs 4 loop configuration)' j

  • Approx 120 analog inputs
  • Approx 250. analog inputs
  • Approx 20 digital inputs
  • Approx 300 digital inputs .)
  • Plant specific keyboard layout
  • Plant specific keyboard layout (Different display hierarchy) (Different display hierarchy)

(

  • Generic PSMS Design Specification l

t

                                                                 *Similar Factory Acceptance Test
                                                                                                                         ]

l l 1 i

                                                                                                                         )

i l 1 l

 '~

ATTACHMENT B .! 1 1 1 4 Beaver Valley Unit 2 Plant Voatle Remote *1 CP/ vital bus I *2 cps / vital bus I I Processina 1 CP/ vital bus II 2 cps / vital bus II 1 Malt 1'CP/ vital bus III 1 CP/ vital bus III  ! ( RPU ) 1 CP/ vital bus IV 1 CP/ vital bus IV

                                                                                    *2 Class IE Dual Bay cabinets                    *2 Class IE Dual Bay cabinets      i 1 non-Class IE cabinet                           2 Class IE Single Bay cabinet     l 1 non-Class IE cabinet            j i
  • Identical 100 RTD input cards
  • Identical 200 RTD input cards
  • Identical 4-20 ma input cards i
  • Identical contact' input cards 1 I
                                                                                                                *!dentical 0-10 V input cards                           !
  • Intel SBC-8605 CP .
  • Intel SBC-519 digital I/O j

,(

  • Modified Data I
  • Translation DT-1742 A/D l
  • Intel SBC-544 Communication Control I
  • Intel SBC-428 PROM board
  • Micro Memory HM 8086/64 CMOS RAM board
  • Identical Self Health board (Westinghouse design)
  • Equivalent system level software
                                                                                    *Similar application algorithms Similar application algorithms (Generic d + p                                   (Generic design l                                                                                      specifications utilized)                         specifications utilized)
                                                                                                                *Similar factory Acceptance Tests 1

L1 ATTACHMENT B  : ( Beaver Vallev Unit 2 Plant Voatle Dftabase *1 CP/ train *1 CP/ train Processina Unit *1 Class IE Dual Bay cabinet 32 Class 1E Dual Bay cabinets. ( DPU )

                                                                                            *RS-422/232 Conversion board input (RPU to DPU)
  • Encode / Decode RS-422 Datalink board (DPU to Display)
  • Intel SBC-8605 CP
  • Intel SBC-428 NVRAM storage
  • Identical Self Health board
  • Intel SBC-519 Digital I/O j i
  • Data Translation DT-104. D/A
  • Intel SBC-88/45 Communication Control  ;

l'

     .(<
  • Intel SBC-428 PROM board
  • Micro Memory MM 8500CC/256K CMOS RAM board
                                                                             *Similar application algorithms *Similar application algorithms (Generic design                    (Generic design                 .l specifications utilized)           specifications utilized)
  • Equivalent system level software
                                                                                            *Similar Factory Acceptance Tests i

h__ . _ _ _ _ _ . - _ _ _ - _ _ . _ _ _ _ _ . _ _ . . . _

ATTACHMENT B' ( Beaver Vallev Unit 2 Plant Voatle Disolav *1 module / train U.Dit

  • Intel.SBC-8605 CP
  • Identical Display Interface (Westinghouse design)
  • Micro Memory MM 8500CC/256K CMOS RAM board.
  • Intel SBC-88/45 Communication Control
  • Identical Utility Interface Control
  • Electro Plasma Dot Matrix Display ( 512x512 )
  • Plant specific display pages
  • Plant specific display. pages (Different display hierarchy) (Different display hierarchy)
                                        *Similar Facte.y Acceptance Tests, t

i Keyboard

  • Identical Keyboard Interface  ;

board

  • Plant specific keyboard layout
  • Plant specific keyboard layout (Different display hierarchy) (Different display hierarchy)
                                        *Similar Factory' Acceptance Tests i

l 1 i

.(

l l l 4

ATTACHMENT C PSMS (TAC 64577 RESPONSE) I. INTRODUCTION The plan described below will be implemented for future software changes on the PSMS. A graphical representation of the PSMS software V&V plan' is provided in Figure 1. The software verification and validation portions of the plan will be performed by a group (s) that is independent from the design team. The PSMS software change V&V plan is scheduled to be implemented prior to start-up following the second refueling outage, II. SOF'NARE VERIFICATION The system verification process verifies the functionality of the software entities. Verification techniques used in software development can fall into two basic categories, review and testing. A. Software Review Three types of reviews that can be used in the verification of software are Design Specification reviews, Source Code reviews and Functional Test reviews. '

1. Design Specification Review l l

The comparison of a Software Design Specification for a subsystem, module, or unit to the Design Specification of the 1 component above it is performed to ensure that all of the  ! performance requirements stated in the higher level document are met. l

2. Source Code Review {

During the Source Code review, the software is examined by qualified independent personnel and operation of the software is deduced and compared with the expected operation. In effect, the operation of the software is evaluated to confirm . that it agrees with the specification. ) Source code reviews verify the transformation from a Design Specification into high level code.

3. Functional Test Review A functional test review is a review by the verifier of the ,

functional test results which were generated by the designer. l The review of the test results provides a high degree of ! assurance that the software performs the functions specified in the design requirements. ,

                                                                                                                                             'i ATTACHMENT C                                                                                                'I
            ,               PSMS (TAC 64577 RESPONSE) 1 B. Software Testing                                                                                                                  i Software testing can be divided into two categories, structural                                                                    ;

and functional. j a

1. Structural Testing Structural testing comprehensively exercises the' software program code and its component logic structures. The'  ;

functionality of the program is' verified in conjunction with the internal structure utilized within the program to implement the required function. 9 Structural testing requires that the verifier inspect.the code and understand how it functions before selecting the test inputs. The test. inputs are chosen to exercise all the possible branches within the software entity. If this is not possible, the test inputs fare then chosen to exercise i i every statement within the software entity. For example, if a trigonometric function is ' calculated in several'different ways, depending on the range of the input argument,-then the  ; test inputs include tests for the argument-in each of these  ? ranges, as well as on the boundaries between ranges. For example, they exercise the upper limit, the lower limit, and at least one intermediate value within each range.

2. Functional Testing
                                                                                                                                                  )

l In the functional approach to program testing, the internal structure of the program is. ignored during the test l selection. Tests are constructed from the functional  ! properties of the program which are defined in the Design Specification. Functional testing is the method most frequently used at the module or subsystem level. . Examples of functional testing include random testing and special cases by function.

                                                                                                                                                 >l Random testing is the method of applying a test input sequence chosen at random.      The method can be used in the following circumstances:     to simulate real time events; to increase the confidence level in the correctness of a very complex module; to test a subsystem or a system where it-is not necessary to test all the possible paths; to get some quantitative measure      on    the accuracy    of a numeric l                  calculation; or to. get a measure of the average time l                  required by some calculation.

l 1

l ATTACHMENT C PSMS (TAC 64577 RESPONSE) Following the above methodologies, the software will be verified and j then entered into the library. The following activities will be , performed to provide the software baseline: i

                            -    Take credit for duplicate software on other installations where the Vendor's software verification program was conducted.                               j 1
                            -    Perform a verification program using a source code review technique                 !

discussed above on the " differences" software using a group independent from the design group. III. SYSTEM VALIDATION A. Validation Philosophy The system validation process is performed to demonstrate the system functionality. The system validation test results demonstrate that the system design meets the system functional requirements. Hence, any inconsistencies that occurred during the system development in this area that were not discovered during the software verification , activities can be identified through the validation process. 1 B. Validation Testing Overview { Validation testing compliments the verification process by ensuring that the system meets its functional requirements. The major phases of the validation process can include the following:

1. Functional requirements testing - ensures that the final system meets the functional requirements. A comprehensive functional requirements decomposition is conducted on all system functional requirements from which the validation test requirements originated.  ;

1

2. Abnormal mode testing -

ensures that the design operates properly under abnormal operating conditions. As an example, the testing may include off-scale high or off-scale low simulation to ensure that proper PSMS response is obtained. 3 System Prudency Review / Testing - ensures that ga4 design practice was utilized in the design and implementa. ion of critical design areas of the system. The Review / Testing requires that the internals of the system design and implementation be analyzed in detail. l 4. Specific Man-Machine Interface testing - ensures that the j man-machine interface utilized to modify the system data base at the maintenance terminal performs properly.

i ATTACHMENT C i 1

                                       ,              PSMS (TAC 64577 RESPONSE)

The macroscopic top-down. functional requirements phase of validation j process treats the system as a black box whereas the prudency review I ' phase requires that the internal structure of the integrated software / hardware system be analyzed in more detail. Due to the dual approach, validation testing provides a level of thoroughness J and testing accuracy which enhances the possibility of detection of j deficiencies that could have occurred during the design process but not discovered during verification. Validation may be performed on verified software residing within the PSMS target hardware or on a test jig. Following the specification of tests associated with the 4 major phases, detailed validation' test procedures are written which i specify the detailed engineering tests and required system  ; responses. The tests are then conducted on the system target hardware or a test jig which incorporates the' system verified software. Deviation between the system response and the desired , results are identified and officially recorded as a Validation j Trouble Report. Typically, the trouble report is then returned to the design group for resolution by. one or more of the following techniques: software change; ' hardware change; validation test j modification; functional requirements / decomposition modification; or no problem identified. If a software or hardware change is required, the revised software must be reverified and subjected.to a validation retest. l l C. Validation Testing of Software Modifications j Validation testing may be performed on a test jig or the PSMS target j hardware. A test jig may be used because the PSMS is made up of I multiple independent micr, processor based subsystems. 'The independence of these subsystems allows a' test jig to be made up of a partitioned subset of the entire set of subsystems, as long as the data flowing into the subset exactly simulates the data flow in the actual PSMS with respect to timing, content, and organization. , i The rationale for performing the validation testing on a test jig for software modifications is that some software modifications may affect as few as one of the PSMS subsystems. As long as the interactions with the other portions of the system are well understood, and are determined to have no impact on previously performed testing, validation testing on a subset of the PSMS will be as effective in assuring correct system performance as testing on the integrated system. In order to maintain the independence of the validation test and to assure the traceability of the validation test to the actual system, the following is required of a test jig:

1. The configuration of the test jig is defined by the validation ,

group. The conflict of the testing being constrained by a ' hardware configuration specified by system designers is avoided.

ATTACIBGENT-C PSMS (TAC 64577 RESPONSE)

2. The hardware environment in which the software under test must operate shall have a traceable' configuration to the PSMS target hardware. This means that the. microcomputer board set, the PROMS, the environment, etc., shall be the same as the PSMS.

target hardware. ' Input signals to the subsystem shall be defined so as to appear to the software to be actual PSMS signals. Any use of hardware boards (CPU, memory) different from the actual PSMS shall be analyzed to demonstrate that their use does not invalidate any testing.. 3 A documented configuration of the test jig shall be maintained and referenced in the validation test plan to provide an audit trail. l IV. VERIFICATION AND VALIDATION TEAM ORGANIZATION The verification and validation team is independent of the design team developing the PSMS asftware. The use of two independent teams introduces diversity to the process of software development and reduces the probability of undetected errors. Additionally such a scheme requires the designer. to produce sufficient and unambiguous documentation before validation. can take place (e.g. functional requirements, design specifications, etc.). l A. Verification Team The typical functions of the verification team are as follows:

1. Review the software design specifications received from the l design team.
2. Evaluate the software changes to determine content and scope.

I 3 Using the software design specification develop software test specifications, perform software testing and issue trouble reports if necessary.

4. Following the resolution of trouble reports, repeat software testing as required.
5. Perform software librarian functions for the storage .and configuration control of the verified software.

B. Validation Team The typical functions of the validation team are as follows:

1. Generate a detailed functional requirements decomposition document which specifies the type of tests that must be conducted in order to demonstrate the system functional requirements are met.

ATTACHMENT C  :

                                                   ,                PSMS (TAC 64577 RESPCNSE)                                ;
                                                                                                                          .l
2. Using the decomposition document as the basis, generate detailed validation testL procedures (e.g. identify . specific terminal screw inputs, required voltage, current and resistance-inputs, etc.). .

3 Conduct the validation tests on the PSMS target system or a test  ; jig. J

4. Compare validation test results with desired test results and issue Validation Trouble Report for any deviations identified.
5. Following the resolution of. trouble reports, repeat validation testing as required.

V. V&V PLAN Figure 1 depicts the .V&V plan for future software changes. The following summary presents the activities of the V&V plan, described-herein. A request for change is processed. 1 The center blocks of activities represent-the Design Team's efforts for J implementing the changes. The functional requirements and design specifications are changed as necessary and forwarded to the validation team. 1 l The firmware modifications are performed and then the design  ! documentation along with the source code is forwarded to the 4 verification team. The verification team activities, sho,m on the right of Figure 1, are I performed by a group independent from the design team. l i A change impact analysis is performed to determine the impact of the

                            ' software changes on the other software components.

A software verification is performed on the source code affected by the change. Any trouble reports are processed back to the design team to correct any software deficiencies. l i l The verified software is then stored in the V&V library. The validation team activities, shown on the left side of Figure 1, are i performed by a group independent from the design team. J A change impact analysis is performed to evaluate the impact the change j has on the system. j i l j

1 1

      .        ....:..                                ATTACIBE3fT C                                      l
                              ,               PSMS (TAC 64577 RESPONSE)                                  ,

The. functional. decomposition. document is' revised to consider the changes and this information is used to r6. vise the validation test procedures as necessary. When all conditions of the validation, design, and verification teams have been. satisfied, factory acceptance / validation. testing is performed. -{ Trouble reports generated by the validation team, if any, are processed' . ~ back.to the design group for resolution. When the. factory acceptance / validation testing is completed satisfactorily,'the results are documented and the V&V-activities for' the particular change are complete.  ! i 4 I l 1 l l l 1 i

ATTACHMENT'C

   . UERIFICAT                      TI M FIAN Sof  I gf FISIE 1                            CHANGE 1 '

e i e 4 l 8 4-Ipcgdesimpactanalysis i S IM $ecesfan,138tei.i>nis

                                                  ;                           i i                           i l                            l v                           l                            l Age         S FIlWMARE    4 i                            i MODIFICATIONS Mfbt                               !                            !
            "W5          W" as necessary l                           l i  '

l i ' i

                                                           "                 !i      'd b V          fM                          A                                       1 '

u necekarv , , VES i i

                                                                                             '/:NO i                            i l                            l              < .

I e i VERIFID - gred in SOFTl44RE l i i e i l l i e i i e i o l " l o l MC 0 l A 'A ken f i l l 1 e 1 i i

           /                                    l                            l i

VES i

A e i e I i NO  ! s
                                                '                            i (ay                                        j l

j l l UALI Mil m IIAM i DESIGN TM N i VIRITICATIM TDM  ! i a j i}}